在J2EE领域来说，SSH/SSI是好东西，是大师们呕心沥血的结晶。但，他也是坏东西。
好的一面，相信不用多说，大量的设计模式运用，极大的降低程序员入门门槛，规范企业应用开发，提高生产效率等等。无论从企业成本抑或个人技术发展方面，都堪称精华之作。
What: SSH/SSI的坏处是什么
现在，我们讨论它坏的一面：
1.降低程序员入门门槛
你只需要一本《xx天学会xx》，就可以参加工作，赢取其他行业羡慕的薪水。但，这真的好吗？！我们不讲程序是算法和数据结构的结合，不讲高大上的理论和技术，我们都是平凡人。从急需就业的角度讲，能让你快速学会一门技术，这是很好的。但是，当很多平凡人尝到了这个急功近利的甜头后，就觉得技术就是这样，我什么时候用到了再临时抱下佛脚，于是不思进取，混吃等死。越来越多的企业应用开发人员进入了这种状态中。有的人知道这是不对的，可是看到别人是这样，自己随大流，也不去改变。
2.规范企业应用开发
从企业生产角度看，能够把本来无法规范的事情，形成规范化的流程化的生产过程，这是非常好的事情，可以大大降低生产成本，提高产品质量。但是，流程的副产物就是僵化！
前面说到，由于入门门槛降低，鱼龙混杂，人员水平参差不齐。对于这种规范，有的人理解他是规范，是参照物，有的人理解他是规定，是必须遵守的准则，再加上不思进取，知其然而不知其所以然，导致这种僵化现象更加严重。
3.大量的设计模式运用
部分开发人员看到框架这么用设计模式，于是看见什么都像钉子，这个与本篇主题关联不大，这里不多讨论。
Why: 为什么这是他的坏处
道理讲完，我们来看具体的例子。
相信很多人在开发SSH/SSI应用时，都要写jsp,action,service,dao这几个典型模块。那么，我为什么开发一个功能需要写这些模块，我为什么不可以用其他的方式来实现？
有人说，因为这是遵循MVC模式，是针对业务的分层模型，更便于开发维护，及与其他开发人员交流。
那么，我们就从MVC入手，看看为什么要这么做开发。
V：View 视图层，也就是直接和用户交互的那一层，是数据展示层
C: Controller 调度层，指将view层的请求转发给服务层，组合调度服务层实现view层的请求，并将服务层的数据返回view层
M: Model 数据模型,指服务层+数据层，也就是常说的 Service+Dao，主要用来实现业务逻辑，并返回业务数据
上面的理论相信每一个J2EE的开发人员都有看过相关介绍。对于View层，我们不多讨论，无论使用哪种View技术，它的目的比较单一，相对比较容易理解。
这里主要说C和M。
常规的做法是，新建Action，新建Service接口，新建Dao接口，新建ServiceImpl实现Service接口，新建DaoImpl实现Dao接口。
这里就回到主题了，为什么一定要这样建这么多类和接口？
很多初级开发人员不管三七二十一，上级这么要求，就这么写，不懂变通，久而久之，就认为web就应该是这样的.....
或者，混淆C和M的职责，造成业务逻辑混乱，代码大量冗余。
How: 正确的做法
那么正确的做法是什么？
一、职责单一，专注
小到一个方法，一个类，大到一个模块，再大到一个系统，它所做的事情应该是单一的，它只应该专注一件事，一个领域。
Controller调度器，既然称为调度器，就不应该存在复杂的业务逻辑，它的职责应该是单一的，就是负责吧下层的服务模块组合排列，实现view层的数据请求。
Service服务层，既然称为服务层，就应该专注于服务，实现所有的业务逻辑，调用并组合Dao层查询方法，不应该存在调度和直接DB请求。
Dao,Database access Object,数据库访问层，专注数据库访问，不应该存在业务逻辑。
二、模块化
前面说到Controller负责调度，那假如我把所有的业务都写到一个service方法里面，action就调了一个方法，别的什么事情也没做，那这个调度是不是就没用的？（service也一样，如果没有业务逻辑，单纯调用Dao方法）。
需求就像一个奇形怪状的建筑物，你有两个选择：
1.直接造一个这样形状的建筑物，满足需求，下一次在直接造。
2.切分，将这个奇形怪状的建筑物切分成规则形状的积木，然后拼接粘合起来。下一次继续切分，慢慢的你手里的规则积木越来越多，你的代码也会越来越好写，每个新需求，你只要利用现有积木加上一点胶水粘起来即可。这时候action,service的真正功能才能体现出来。
这里说的积木就是模块，这个模块可以是一个方法，一个类，一个封装完整的功能。
相信都能看出来那种方法是好的，但是为什么大多数人都要采用第一种方法来写代码呢？
三、大而化之
在职责和模块讨论清楚后，我们来考虑，view/action/service/dao到底是什么，可否换一种写法，当我们在分层的角度，在来看他们，其实他们只是一种层次的划分，上层依赖下层，下层为上层提供服务，框架定义了我们要这样分N层来写。那我也完全可以自己定义分四层，五层...只要业务需要,于是这就形成了一种属于你自己的编程思想。
上面三步需要一步步走扎实，当然，刚开始肯定是比较困难的，也许比你平常写代码还要困难，也更慢，这时候你需要一种品质：处女座(追求极致)！ :)
Then: 终言
我们都知道java世界的工具框架很多，对于工程化开发来说，专注业务，不用造轮子，不错！但是对于开发人员自己来说，就很容易造成思维僵化，入门容易，基础差，提升困难！
这也应该是C程序员转java容易，java程序员转C困难的一部分原因吧！毕竟很多老C程序员是自己维护自己的工具库，而这工具库是自己一个个码出来的。宝剑锋从磨砺出，外部环境的优沃常常造成基础的不牢固。
常常说懒是一个程序员的优秀品质，因为计算机本身就是懒的产物。但是，在夯实基础时，必须苦功夫，笨功夫，追求极致，凡事多问多想几个为什么，你才能有懒的资本。
任何事情都有两面，过犹不及，中庸不等于平庸！