从分层模型谈三种耦合

1      分层架构的缘由

通常我们在做J2EE项目的技术架构时，通常会考虑一种分层的模型，目前非常流行的分层做法是控制层一般采用struts,springmvc，在业务层采用spring，EJB，在持久层采用hibernate,ibatis，jdbcTemplate等。那么为什么要采用这种模型呢？这是我们需要考虑的问题。

其实采用分层模型主要目的是为了解耦，为什么需要解耦？因为我们的项目是做应用解决方案的，它是一种定制化系统，而定制化系统的一个比较明显的特征是需求的随时变更，而为了去适应这种变更我们不得不从两方面去解决这个问题，一方面是售前侧，即让售前与客户沟通，尽量回避需求的变更（相信做过售前的人会明白要想让客户明确自己想要什么是有多么地困难），而另一方面则是通过技术手段进行解决，即构建一个灵活的，充分解耦的技术框架，以期能够快速地对需求变更做出响应。自然，从技术层面来说，构建一个分层模型的架构就是为了去适应需求的不断变更，尽最大可能地进行解耦。为什么分层模型能够做到解耦呢？

因为对一个系统进行分层处理，就是为了将一个系统按其功能的最终呈现而进行职责的分离，不同的层次进行不同职责的功能划分，比如展现层用来对数据进行展现的，控制层主要用于进行业务请求控制的，业务处理层主要用于进行业务逻辑处理的，持久层主要用于进行数据持久化和读取的。为什么这么分呢？因为人们发现按这种方式对整个业务进行分离之后，带来了很大的好处，比如某一处的修改，只会对本层有一定的影响，而不会影响其他层，这样就做到了修改最少，风险最小。在一个非常复杂的系统中，甚至于根据业务逻辑会构建更加多的层。