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

为了回答楼主的帖子，特地把N年前的账号翻出来，又通过javaEye麻烦的发帖测试。
首先赞赏楼主一下，你是动脑子的人，有自己独立见解。
我99年就开始做java，之前时机也抓的比较好，做php也是国内第一批开发者和推广者，桌面开发用的delphi。刚开始的时候，跟大家一样，那时候讲起java就觉得牛逼。
2000年的时候因为算是做ejb的第一批人，被当时bea公司到处介绍案例，那时是我的黄金时代。但是我心里面明白的很，ejb到底是一个什么样的东西，属于上了贼船，心里明白但是绝对不能说出来，在各种会议上务必还要吹嘘ejb的好，这也是配合大家。你要知道，当时候的ejb版本也就是1.1，在当时的硬件环境下，项目中使用ejb真是一件令人苦恼的事情。
2002年的时候开公司，自己做老板，心里面就明白多了，用最合适的技术！什么叫好技术？开发速度快，运行效率高，维护成本低。在使用任何技术前都要经过这些考量。如此一直到了今天。
但是我承认，跟风是技术人员起飞的最佳时机，一定要站在最前面，不要太靠前，也不要太靠后，太靠前会成为先烈，恰到好处会成为先驱，太靠后的真的是遗老遗少啦！
其实很多做java的，都是02年之后才开始做，先入为主很要命，先是struts/webwork，然后是hibernate，最后是spring。他们的概念里面，如果离开了这几样，那简直不知道怎么去用java开发，其实为什么用这几样，他们也不是太清楚，只是因为大家都用了，所以我也要用。说白了，就是某些技术宣传的炮灰。
你知道robin怎么起家的么？就是靠在国内积极推广hibernate和spring，现在他在干嘛？早就已经转向了！可怜这些炮灰还没有转过弯来。
06年底，我给一家公司做技术咨询，他们所谓的架构师，是一个从02年才接触java的人，之前没有其他语言的开发经验。就是这么一个人，用的spring+hibernate+ssh，分三层dao+service+action，随便开发一个功能模块，没有十几二十个文件，压根就搞不定，修改一个小功能，这十几二十个文件都要改，所以开发效率特别低，不仅仅开发效率低，运行效率也很低，系统启动没有1分钟启动不起来，程序员想Debug一下，费老鼻子劲儿了，系统起来之后运行效率也很低。他会觉得愧疚么？不会，他觉得理所当然！速度慢是因为服务器配置低，数量少。
说实话，这种分层真的不算技术，也压根算不上架构。一个开发速度慢，运行效率低的系统设计，值得存在么？
系统设计首先应该是必须的，能够解决问题的，而不是为了某种莫须有的需求存在。这方面来说，spring的存在价值可能真的很可疑。
1.大部分的系统，除了做产品，特别是做项目，在整个生命周期内，都不会更改数据库服务器的类型。
2.大部分的业务系统，系统内部所谓面向接口的设计，都是无效的，这是在浪费开发时间和运行效率。真正的接口设计，应是跨平台、语言的，否则就是低效设计。
3.大多数时候，不确定的重用都是想当然的。有时候，重构真的比在老系统上修改，更简单，更高效，更能持久。

随手写写，看电视去了

看poeaa，layer就是一种架构模式
几乎所有的模式都是一个目的：解耦

分层就是为了简单问题复杂化，复杂问题简单化

正解——具体还要看项目需求的

简单的，就不要搞来搞去了，拔出刀子插入心脏就完事儿了，不要理会那些“看到SQL写到Action控制器里以为脑残”的童鞋。。

Spring的重点是接口设计，说明白点儿就是实现代码还没写，就可以约定好各个类、方法的作用和调用，待接口被实现后再配置一下XML文件即可实现功能。

如果设计做不到这一步的话，Spring的意义确实不大，但按照Spring原意的思路去做的话起码看起来更规范，给我自己的感觉而言就像做软件跟做网站的区别那般。

 

以DAO为例 通常定义一个DAO接口 一个 DAOImpl实现类
理由是应该面向接口 而不是面向实现 解除了Service层与DAO的耦合.

但是实际呢? 有几个在业务变动的时候去重新写一个DAO接口的实现? 都是在原有的DAOImpl上修修改改.
而且DAOImpl中方法的参数需要追加的时候 接口也需要跟着变动. 那么面向接口还有什么意义?

设计上如何考虑方法参数变化这点?

分层：
1、首先它给人的感觉就是系统有层次感，不混乱-便于开发与维护。
2、层次明显 各层开发人员专注各自一块 开发效率比较高。

最后提示：
具体情况 具体分析 视项目的规模与后期维护来定，过分分层、MVC也会带来一些不便：
1、开发与维护代码工作量加大 从而在一定程序上影响到项目进度。
2、系统文件过多不利于维护。

除非项目组织很好，否则很多项目将会不可被重构。
在很多team里面，如果不用SSH之类套住程序员，项目极易失控。
有一点需要注意，不是每个项目组都有架构师的，如果没有架构师就不用任何架构，那显然不如直接上SSH来得好。
我目前就有一个02年的项目，采用公司内部框架，没人愿意维护，无法重构，只能重写。

主要还是为了以后的维护吧，如果不需要维护几个jsp就搞定了

我本人很不喜欢强制分层，程序的层次结构应该跟着业务需求和设计方式来定。现在很多项目一上来就把开发规定死了什么ACTION-SERVICE-DAO，这种一刀切的设计根本不能算做设计，最多算是编码规范吧。
P.S.我深恶痛绝DAO