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

今天偶然发现一个兄弟发的牢骚： 主题：一个“过度设计”的项目，快把我弄晕了，进去看了看，反响还挺大。

类似的话题以前也讨论过多次，不过我还是把内容都看了一遍，似乎有些人有点各说各话，所以很想了解一下基本问题大家对于分层都是怎么考虑的，对我们做java应用常见的分层（jsp、action、do/vo、bo、dao......）该如何理解呢？

我先列几个常见的说法和相应的问题，大家可以进行说明，如果有其它原因也欢迎补充

• 为了符合MVC的模型 —— 为什么要符合MVC呢？MVC到底是在解决什么问题？
• 为了分离业务逻辑 —— 这里的业务逻辑是指什么？能否举个例子说明必要性？
• 为了隔离数据库的变化（例如更换数据库） —— 实际使用中有没有更换过数据库？如果更换过，是不是真的隔离了变化，不用大动干戈了呢？

自己开发多几个项目就知道了，说也不明白。其实软件最重要的是后期维护，业务会变化，业务要扩展，软件要更新，时时变化，不按照找一定的模式设计，后期维护难。重新开发成本高。java设计模式中，大多是提高组件重用的。

一般来说项目一期是crud 但是二期 三期就不是了，
业务逻辑这东西才会出来，一期的service可能很薄甚至很多就是调用dao方法
等到了二期三期service方法会有for循环 if else 语句对数据加工抽取以及调用第三方类库等。所以还是不要轻易说action等同于service层

问题一：你会把业务逻辑写在jsp页面上吗？不会吧 理由就不说了
问题二：业务逻辑一般都在service，你开发项目的时候是不是把调用业务逻辑的代码都写在servlet中，我想也不会吧
问题三：你说的很对，虽然这样做了，但到真正跟换数据库的时候难免要大动干戈，但是想一下，如果按你说的，那么整个系统我想没改的必要了  ，干脆重新开发得了 ， 我们只能说隔离数据库的变化，目的是为了跟换数据库的时候，把改动的幅度降到最低就达到目的了 ，不可能完全隔离

解耦合， 下一层的变动不至于引起上层的变动。

这东西根本就取决于设计师口味，没法统一。

分层是一种通用的思维方式，并不是软件行业独有。这个还得追溯到问题分解的领域，将问题分解至可控的粒度。。。

哎，感冒了，话比较多。谅

用三层体系架构有很多原因，但我知道一个最原始的：就是该死的web让http协议是无状态的！

有一次我的一个同事在ACTION里写了好多业务代码，当时确实没问题。

但是后来来个需求，说要把原来显示在页面的数据呈现在EXCEL里。。。然后就晕了，因为ACTION是没办法复用的，这个时候他才明白为什么要有SERVICE这一层。