【SSH2框架（理论篇）】--SSH2 Vs 经典三层



这几天一直在学习使用SSH2框架。对于框架本身的使用并非非常困难。相信经过多锻炼就行熟练的掌握框架的使用，让我匪夷所思的是在使用框架的时候感觉非常熟悉，好像在哪里用过似得。

就在某次查看代码的时候突然闪现了一个想法，SSH2框架和经典三层非常相似。当然经过翻阅资料发现我的想法还是有理论根据的，接下来将会证实该猜想。

一、SSH2初识

我们通常所说的SSH2框架事实上是有三种框架集成的。它们各自是基于MVC模式的Struts2框架和基于IoC模式的 Spring框架以及对象/关系映射框架Hibernate，之所以会产生这么框架是由于J2EE的诟病，由于J2EE的多层结构过于复杂，想要更加效率的开发大型的J2EE项目就必须运用其他的框架和设计模式来整合这样的多层结构提高软件的质量。

Note:框架一般具有即插即用的可重用性、成熟的稳定性以及良好的团队协作性。

想要深入了解SSH框架就必须来看看它的框架图。从它的框架图上来讨论分析它的运行过程。例如以下图为SSH框架的基本结构图。

系统的基本业务流程：在表示层中。首先通过JSP页面实现交互界面，负责接收请求(Request)和传送响应(Response)。然后Struts依据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给对应的Action处理。在业务层中，管理服务组件的Spring IoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完毕业务逻辑，并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。而在持久层中。则依赖于Hibernate的对象化映射和数据库交互，处理DAO组件请求的数据。并返回处理结果。
具体的内部框架的请求过程会在下篇博客中具体讨论。

二、SSH2 Vs 经典三层

先来回想下经典的三层架构，在开发时为了实现程序解耦的目的，我们把程序分成了三个层次。各自是显示层（User Show Layer）、业务逻辑层（Business
Logic Layer）、数据持久层（Data Access Layer）。这是最基础的开发架构，也就是将程序依照我们通常理解的那样拆分开，每一层仅仅专注一种事物，这样每一层仅仅要实现对应的接口就能非常好的减少了程序集之间的耦合。

Note：在有的教程中三层架构可能会有实体层（Entity
Layer），事实上它是三层中的參数。各层之间进行參数传递时须要採用的即为实体层中的表实体。

联系经典的三层我们不难看出SSH2框架的实现事实上就是经典的三层结构。仅仅只是在三层结构中的每一层中集成的是单独的框架，尤其是在表示层中採用的是基于MVC模式的Struts2来配置，当页面进行请求后Struts会依据配置文件（Struts2中为Struts2.xml）将ActionServlet接收到的Request请求托付给对应的Action处理。

然后在业务层中，管理服务组件的Spring IoC负责向Action提供业务模型（Model）组件等来完毕业务逻辑。

而在持久层中，则依赖于Hibernate的对象化映射和数据库交互，处理DAO组件请求的数据，并返回处理结果。

结语

通过上面的对照不难发现事实上SSH2框架採用的是经典的三层模式。将J2EE分层结构进行了良好的整合，在开发时非常方便。可是对于每一个框架的内部运行机制没有做过多的讨论。相信在理解上可能会有非常多疑惑。为了解决疑惑，将会在下篇文章中重点讨论Struts、Spring、Hibernate框架的内部运行机制。