开发为什么要分层，征求大家的意见

1.mvc是为了分离，解耦，复用
2.很多例子，看看你们的项目代码
3.现在没出现不代表以后不出现。
当然mvc也是有利有弊的。权衡罢了。

看了看大家的回复，老实说还是觉得不够丰富，有人看来认为“不要在jsp里面写逻辑，要有service层“是理所应当的事情，但是我提出这个问题正是希望能够引起思考，即使是follow正确的做法，如果不知道这么做的原因，你依然不可能把事情做对。

整理一下，只有两个人提到了自己对分层原因的理解：


rmn190的表达显然有利于进一步讨论，因为他提出了一个很具体的原则“下一层的变动不至于引起上层的变动“，实际上这也是我最近一直在考虑的问题，有空详细说

这只是一方面-依赖倒置的问题。契约型编程建议这么做，不过代码分层只是一个途径，并不是唯一的途径。

可以这么看，如果不做这些设计的话要怎么处理相对应的问题呢？
1.如果没有MVC，是否有更好的分层结构，如果没有，那使用MVC便成为最佳选择
2.如果不分享业务逻辑，那业务逻辑与一些技术上的实现就在一起，到时无论是一些系统技术上的升级或者是业务逻辑的改动都会改动到同一段代码，这并非说一定会有问题，但事实上这种情况明显加重维护人员的技术及业务要求，如果该人员分不清那就杯具了
3.如果没有隔离数据库层，更换数据库势必造成整个系统重写
个人觉得设计都是在考虑如果以后出现扩展或变化，该设计能将改动降低到最少即可，没有可能会有一个设计能够满足各种不同类型的需求，系统成长到某一阶段，原先优秀且经过良好设计的系统也必然会显得设计糟糕

加多一个ACTION也很好解决啊？

这个倒不是问题，action可以复用的。

PO,VO层是面向对象设计的产物，相比于使用Map更加直观，面向对象之后便拥有继承等特性，方便扩展。
DAO，数据库访问层，将数据模型与控制层分离。
service层，故名思意，服务层。
Action，强化的Servlet而已。
Action负责将数据封装成对象或者以参数形式传入service层，将service返回数据组织之后response过去，说白了，只处理request和response对象，不对request的数据本身作任何处理，包括合法性验证，否则，service层没任何意义。
Action的作用：处理Http协议相关操作，不对数据本身进行任何操作，对数据的收和发以及封装操作。
service层：服务层，处理请求数据，数据的所有相关操作都在这里处理。

举个简单例子：有一个项目，最初为BS结构，按照Dao、Service、Action三层设计，项目完成之后，新需求，需要将一部分功能做成CS结构，只需将Action中处理的Http协议转换为处理自定义socket协议即可。
若不分service层，Action充当控制器，则服务端代码基本上是在重写一个控制层。

说得好！
与其说DAO层是为了隔离数据库的变化，还不如说是将对数据的操作抽出一层。
所有的设计模式和分层说到底就是为了在需求变化时，缩小改动的范围。
如果需求铁定不改，系统铁定不用维护，那么什么设计模式和分层都是白搭！

    降低代码之间的耦合度，提高代码的重用性。

为了管理。人也有等级，公司也有等级和分部门，等等。。。。太多了。项目也一样的理