在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程序员是自己维护自己的工具库,而这工具库是自己一个个码出来的。宝剑锋从磨砺出,外部环境的优沃常常造成基础的不牢固。
常常说懒是一个程序员的优秀品质,因为计算机本身就是懒的产物。但是,在夯实基础时,必须苦功夫,笨功夫,追求极致,凡事多问多想几个为什么,你才能有懒的资本。
任何事情都有两面,过犹不及,中庸不等于平庸!