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

article/2025/11/6 18:41:53

这几天一直在学习使用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组件请求的数据，并返回处理结果。