各位开发过的业务系统都是怎么分层的

说到分层，做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中。

 

对于分层，不是很好说，业务系统讲究的是实现和可维护，我每次工作都是火急火燎要求很紧张，很少时候是有对于系统设计好了再去做的。所以我不会分那么多层，越简单越好，这样不管什么样的程序员都容易去上手。

但是简单分层有一个有点，那就是要把公共方法合理抽取，并单独建立包提供给大家使用。

 

之前做的是传统上的业务系统，现在做的涉及数据库和网络编程等多方面，不管怎么样，对于系统的分层，如何才能合理，大家还是讨论一下吧！

手头上正做一个项目，struts2做的。主要分层DAO层，MODEL层，service层，VIEW层。小项目怎么做，都行啦。

MVC不应该理解为分层设计，如在传统的MVC中，C和V都在表现层。
MVC是架构型模式，职责在于分离表现和业务逻辑，分离后通过C进行协调。因此仅仅是一种模式！

分层吧，逻辑上分层不会增加工作量，就是多了一个包而已。如果不这么做迟早会后悔，特别是新人技术不好，到时候胡乱写代码，把jdbc代码都写到action中去，你就崩溃了。

分层有架构设计的考虑，也有管理方面的考虑.

确实，少一层减少一些代码量；不过中间加一层，对于以后维护和扩展的好处是可取的。

如果项目时间紧，可以省略中间一层，但是以后项目更新维护可以加上，有利于以后维护。

其实这个东西吧..分层来说..按自己的习惯吧..一般都是MVC这种.

必要的分层是一种很好的解耦，好处以后会体现出来的~

说的不错，MVC的概念貌似很容易懂，但真正理解起来就应该是酱紫的