這幾天一直在學習使用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框架的內部運行機制。

【SSH2框架（理論篇）】--SSH2 Vs 經典三層