ssh

Struts對Model，View和Controller都提供了對應的組件。分為Struts1和Struts2，區別甚大。

Action，這個類通常由用戶提供，該控制器負責接收來自ActionServlet的請求，並根據該請求調用模型的業務邏輯方法處理請求，並將處理結果返回給JSP頁面顯示。

由ActionForm和JavaBean組成，其中ActionForm用於封裝用戶的請求參數，封裝成ActionForm對象，該對象被ActionServlet轉發給Action，Action根據ActionForm裡面的請求參數處理用戶的請求。

JavaBean則封裝了底層的業務邏輯，包括資料庫訪問等。

該部分採用JSP（或HTML、PHP……）實現。

Struts提供了豐富的標籤庫，通過標籤庫可以減少腳本的使用，自定義的標籤庫可以實現與Model的有效交互，並增加了現實功能。對應上圖的JSP部分。

Controller組件有兩個部分組成——系統核心控制器，業務邏輯控制器。

系統核心控制器，對應上圖的ActionServlet。該控制器由Struts框架提供，繼承HttpServlet類，因此可以配置成標註的Servlet。該控制器負責攔截所有的HTTP請求，然後根據用戶請求決定是否要轉給業務邏輯控制器。

業務邏輯控制器，負責處理用戶請求，本身不具備處理能力，而是調用Model來完成處理。對應Action部分。

Spring是一個開源框架，它由Rod Johnson創建。它是為了解決企業應用開發的複雜性而創建的。Spring使用基本的JavaBean來完成以前只可能由EJB完成的事情。然而，Spring的用途不僅限於伺服器端的開發。從簡單性、可測試性和松耦合的角度而言，任何Java應用都可以從Spring中受益。

目的：解決企業應用開發的複雜性

功能：使用基本的JavaBean代替EJB，並提供了更多的企業應用功能

範圍：任何Java應用

簡單來說，Spring是一個輕量級的控制反轉(IoC)和面向切面(AOP)的容器框架。

輕量——從大小與開銷兩方面而言Spring都是輕量的。完整的Spring框架可以在一個大小隻有1MB多的JAR文件里發布。並且Spring所需的處理開銷也是微不足道的。此外，Spring是非侵入式的：典型地，Spring應用中的對象不依賴於Spring的特定類。

控制反轉——Spring通過一種稱作控制反轉（IoC）的技術促進了松耦合。當應用了IoC，一個對象依賴的其它對象會通過被動的方式傳遞進來，而不是這個對象自己創建或者查找依賴對象。你可以認為IoC與JNDI相反——不是對象從容器中查找依賴，而是容器在對象初始化時不等對象請求就主動將依賴傳遞給它。

面向切面——Spring提供了面向切面編程的豐富支持，允許通過分離應用的業務邏輯與系統級服務（例如審計（auditing）和事務（transaction）管理）進行內聚性的開發。應用對象只實現它們應該做的——完成業務邏輯——僅此而已。它們並不負責（甚至是意識）其它的系統級關注點，例如日誌或事務支持。

容器——Spring包含並管理應用對象的配置和生命周期，在這個意義上它是一種容器，你可以配置你的每個bean如何被創建——基於一個可配置原型（prototype），你的bean可以創建一個單獨的實例或者每次需要時都生成一個新的實例——以及它們是如何相互關聯的。然而，Spring不應該被混同於傳統的重量級的EJB容器，它們經常是龐大與笨重的，難以使用。

框架——Spring可以將簡單的組件配置、組合成為複雜的應用。在Spring中，應用對象被聲明式地組合，典型地是在一個XML文件里。Spring也提供了很多基礎功能（事務管理、持久化框架集成等等），將應用邏輯的開發留給了你。

所有Spring的這些特徵使你能夠編寫更乾淨、更可管理、並且更易於測試的代碼。它們也為Spring中的各種模塊提供了基礎支持。

Hibernate是一個開放源代碼的對象關係映射框架，它對JDBC進行了非常輕量級的對象封裝，使得Java程序員可以隨心所欲的使用對象編程思維來操縱資料庫。 Hibernate可以應用在任何使用JDBC的場合，既可以在Java的客戶端程序使用，也可以在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成數據持久化的重任。

Hibernate的核心介面一共有5個，分別為:Session、SessionFactory、Transaction、Query和Configuration。這5個核心介面在任何開發中都會用到。通過這些介面，不僅可以對持久化對象進行存取，還能夠進行事務控制。下面對這五個核心介面分別加以介紹。

·Session介面:Session介面負責執行被持久化對象的CRUD操作(CRUD的任務是完成與資料庫的交流，包含了很多常見的SQL語句。)。但需要注意的是Session對象是非線程安全的。同時，Hibernate的session不同於JSP應用中的HttpSession。這裡當使用session這個術語時，其實指的是Hibernate中的session，而以後會將HttpSesion對象稱為用戶session。

·SessionFactory介面:SessionFactory介面負責初始化Hibernate。它充當數據存儲源的代理，並負責創建Session對象。這裡用到了工廠模式。需要注意的是SessionFactory並不是輕量級的，因為一般情況下，一個項目通常只需要一個SessionFactory就夠，當需要操作多個資料庫時，可以為每個資料庫指定一個SessionFactory。

·Configuration介面:Configuration介面負責配置並啟動Hibernate，創建SessionFactory對象。在Hibernate的啟動的過程中，Configuration類的實例首先定位映射文檔位置、讀取配置，然後創建SessionFactory對象。

·Transaction介面:Transaction介面負責事務相關的操作。它是可選的，開發人員也可以設計編寫自己的底層事務處理代碼。

在Struts + Spring + Hibernate的組合框架模式中，三者各自的特點都是什麼？

Struts 的MVC設計模式可以使我們的邏輯變得很清晰。

Spring 的IOC和AOP可以使我們的產品在最大限度上解藕。

hibernate的當然就是實體對象的持久化了

典型的J2EE三層結構，分為表現層、中間層（業務邏輯層）和數據服務層。三層體系將業務規則、數據訪問及合法性校驗等工作放在中間層處理。客戶端不直接與資料庫交互，而是通過組件與中間層建立連接，再由中間層與資料庫交互。

表現層是傳統的JSP技術，自1999年問世以來，經過多年的發展，其廣泛的應用和穩定的表現，為其作為表現層技術打下了堅實的基礎。

中間層採用的是流行的Spring+Hibernate，為了將控制層與業務邏輯層分離，又細分為以下幾種。

Web層，就是MVC模式裡面的“C”（controller），負責控制業務邏輯層與表現層的交互，調用業務邏輯層，並將業務數據返回給表現層作組織表現，該系統的MVC框架採用Struts。

Service層（就是業務邏輯層），負責實現業務邏輯。業務邏輯層以DAO層為基礎，通過對DAO組件的正面模式包裝，完成系統所要求的業務邏輯。

DAO層，負責與持久化對象交互。該層封裝了數據的增、刪、查、改的操作。

PO，持久化對象。通過實體關係映射工具將關係型資料庫的數據映射成對象，很方便地實現以面向對象方式操作資料庫，該系統採用Hibernate作為ORM框架。

Spring的作用貫穿了整個中間層，將Web層、Service層、DAO層及PO無縫整合，其數據服務層用來存放數據。

一個良好的框架可以讓開發人員減輕重新建立解決複雜問題方案的負擔和精力；它可以被擴展以進行內部的定製化；並且有強大的用戶社區來支持它。框架通常能很好的解決一個問題。然而，你的應用是分層的，可能每一個層都需要各自的框架。僅僅解決UI問題並不意味著你能夠很好的將業務邏輯和持久性邏輯和UI 組件很好的耦合。

不可否認，對於簡單的應用，採用ASP或者PHP的開發效率比採用J2EE框架的開發效率要高。甚至有人會覺得：這種分層的結構，比一般採用JSP + Servlet的系統開發效率還要低。

筆者從以下幾個角度來闡述這個問題。

— 開發效率：軟體工程是個特殊的行業，不同於傳統的工業，例如電器、建築及汽車等行業。這些行業的產品一旦開發出來，交付用戶使用后將很少需要後續的維護。但軟體行業不同，軟體產品的後期運行維護是個巨大的工程，單純從前期開發時間上考慮其開發效率是不理智的，也是不公平的。眾所周知，對於傳統的ASP和 PHP等腳本站點技術，將整個站點的業務邏輯和表現邏輯都混雜在ASP或PHP頁面里，從而導致頁面的可讀性相當差，可維護性非常低。即使需要簡單改變頁面的按鈕，也不得不打開頁面文件，冒著破壞系統的風險。但採用嚴格分層J2EE架構，則可完全避免這個問題。對表現層的修改即使發生錯誤，也絕對不會將錯誤擴展到業務邏輯層，更不會影響持久層。因此，採用J2EE分層架構，即使前期的開發效率稍微低一點，但也是值得的。

— 需求的變更：以筆者多年的開發經驗來看，很少有軟體產品的需求從一開始就完全是固定的。客戶對軟體需求，是隨著軟體開發過程的深入，不斷明晰起來的。因此，常常遇到軟體開發到一定程度時，由於客戶對軟體需求發生了變化，使得軟體的實現不得不隨之改變。當軟體實現需要改變時，是否可以儘可能多地保留軟體的部分，儘可能少地改變軟體的實現，從而滿足客戶需求的變更？答案是——採用優秀的解耦架構。這種架構就是J2EE的分層架構，在優秀的分層架構里，控制層依賴於業務邏輯層，但絕不與任何具體的業務邏輯組件耦合，只與介面耦合；同樣，業務邏輯層依賴於DAO層，也不會與任何具體的DAO組件耦合，而是面向介面編程。採用這種方式的軟體實現，即使軟體的部分發生改變，其他部分也儘可能不要改變。

注意：即使在傳統的硬體行業，也有大量的介面規範。例如PCI介面、顯卡或者網卡，只要其遵守PCI的規範，就可以插入主板，與主板通信。至於這塊卡內部的實現，不是主板所關心的，這也正是面向介面編程的好處。假如需要提高電腦的性能，需要更新顯卡，只要更換另一塊PCI介面的顯卡，而不是將整台電腦拋棄。如果一台電腦不是採用各種介面組合在一起，而是做成整塊，那將意味著即使只需要更新網卡，也要放棄整台電腦。同樣，對於軟體中的一個個組件，當一個組件需要重構時，盡量不會影響到其他組件。實際上，這是最理想的情況，即使採用目前最優秀的架構，也會有或多或少的影響，這也是軟體工程需要努力提高的地方。

技術的更新，系統重構：軟體行業的技術更新很快，雖然軟體行業的發展不快，但小範圍的技術更新特別快。一旦由於客觀環境的變化，不得不更換技術時，如何保證系統的改變最小呢？答案還是選擇優秀的架構。

在傳統的Model 1的程序結構中，只要有一點小的需求發生改變，將意味著放棄整個頁面。或者改寫。雖然前期的開發速度快，除非可以保證以後永遠不會改變應用的結構，否則不要採用Model 1的結構。

採用Hibernate作為持久層技術的最大的好處在於：可以完全以面向對象的方式進行系統分析、系統設計。

DAO模式需要為每個DAO組件編寫DAO介面，同時至少提供一個實現類，根據不同需要，可能有多個實現類。用Spring容器代替DAO工廠

通常情況下，引入介面就不可避免需要引入工廠來負責DAO組件的生成。Spring實現了兩種基本模式：單態模式和工廠模式。而使用Spring可以完全避免使用工廠模式，因為Spring就是個功能非常強大的工廠。因此，完全可以讓Spring充當DAO工廠。

由Spring充當DAO工廠時，無須程序員自己實現工廠模式，只需要將DAO組件配置在Spring容器中，由ApplicationContext負責管理DAO組件的創建即可。藉助於Spring提供的依賴注入，其他組件甚至不用訪問工廠，一樣可以直接使用DAO實例。