分层思考

在SSH的开发过程中，常见的分层为：Action层,Service层,Dao层,JavaBean层,其它常量类，工具类，国际化类，Model类，还有视图层。

Action就是常见的Struts2等，Service是定义的一些列业务接口，Dao是定义的操作数据库类，JavaBean是对数据库的一个映射类，Model类是执行具体业务逻辑时为视图层服务。那么这样分层有什么作用呢？它对定义者有哪些要求？

要想做到分层的清晰和合理，需要建立在对系统的整个详细设计上，这时你可能会说这跟迭代开发冲突，其实不然，每次迭代是对上次的补充和修正，并且每次迭代范围确定后详细设计是必须的。对系统的整体把控，对系统的运作方式以及交互方式，我们都有了一个清晰的认识，此时建立出来的框架和结构才有可能是合理的。

分层的第一个好处，大家都能提到解耦两个词。细细分析，解耦意味着我们的各个层的内聚性要很高，各层之间的耦合度降低。每一层的修改不会导致其它相关层次的改动。要做到这样，应该如何考虑。比如：在Service层我们进行相关的业务逻辑处理并封装成试图层所需要的Model类型或者其它类型或者JavaBean，在Action层我们控制展现哪个试图，在试图层我们使用Model或JavaBean来构造视图层数据，这样看起来是解耦了，但是我们在每一层都侵入了Model或JavaBean。并没有很好的解耦。如下图：

因此我们需要引入另外的两个概念叫做模型层和数据层，Model类所在为模型层，JavaBean所在为数据层，这样我们在Service层只出现JavaBean，而在Action层只出现Model，在视图层出现其想要的数据结构，比如xml,json等，这些数据的封装应该是在视图层来实现。然而对于jsp由于jstl的强大支持，视图层中页面的语法更加简单，直接model.property，相对于model的侵入来说还是值得的，我们通常看到的Model层的改动还是很小的，一般都是为了迎合视图层。如下图：

分层的第二个好处，团队合作。当系统的结构被清晰的定义完毕后，对于开发就是一个分工合作的过程，不同的人开发的周期不同，负责的模块不同，如果我们混淆在一起开发，那么工作将无法开展，比如A开发的比较快，B开发的比较慢，但是A中的某个功能需要B的支持才能完成因此他必须要等待B，此时的耦合度太高了，导致整个系统的开发周期增长。分层之后，A和B就可以独立的进行开发和单元测试。并且对SVN的使用也不会因为多人开发而出现很大的冲突。为了避免很大的冲突最好是一个人负责一个模块或一个Service接口。

分层的第三个好处，后期维护。系统完毕上线后，免不了会发现系统中的bug，如果代码混合在一起，对于bug定位来说那是很困难的，需要通读整个代码才有可能找到问题，如果采用分层，那么可以将问题放到各个层次上去考虑，逐层分析定位。问题确认后只会改动某一层而不会因为改动而影响整个代码，这样产生其它bug的概率就降低了。