各位开发过的业务系统都是怎么分层的
说到分层，做java都会想到MVC，这算是整体开发的一种模式，那么不知道各位后台业务处理时是怎么分层的呢？
?
说说MVC，MVC是三个单词的缩写，分别为： 模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现。 View层用于与用户的交互，通常用JSP来实现。 Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。
?
如果按照理论和学习到的来说，后台的处理要再进行合理的分层，就拿Spring+Struts+Hibernate来说，一般Struts的Action来一层，Hibernate的数据库处理来一层，而Action和Dao中间一般再来一层，成为Service层。如果需要，可能还需要再分一层，不过我还没见过。
?
我做过几个系统了，发现做业务应用的系统一般都是基于一个开发的平台，而对于开发人员来说，一般也不会再分那么多层了，直接Action来一层，Dao来一层。
我也是就这么过来了，在今天我带的组要开发的系统时，新来的员工说要在Dao和Action中间分一层，可是我觉得没有这个必要。我们的总体业务逻辑其实不是很难，所以我觉得相对于数据库的操作，只需要两层就可以了。
需要公共方法和与网络交互的，我再建立新的包专门处理，而不会嵌套在Service中。
?
对于分层，不是很好说，业务系统讲究的是实现和可维护，我每次工作都是火急火燎要求很紧张，很少时候是有对于系统设计好了再去做的。所以我不会分那么多层，越简单越好，这样不管什么样的程序员都容易去上手。
但是简单分层有一个有点，那就是要把公共方法合理抽取，并单独建立包提供给大家使用。
?
之前做的是传统上的业务系统，现在做的涉及数据库和网络编程等多方面，不管怎么样，对于系统的分层，如何才能合理，大家还是讨论一下吧！
<property name="target"><ref local="aServiceImpl"/></property>