SSH框架在項目中的做用及原理

典型的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實例。 優勢： Struts跟Tomcat、Turbine等諸多Apache項目同樣，是開源軟件，這是它的一大優勢。使開發者能更深刻的瞭解其內部實現機制。 除此以外，Struts的優勢主要集中體如今兩個方面：Taglib和頁面導航。Taglib是Struts的標記庫，靈活動用，能大大提升開發效率。另外，就目前國內的JSP開發者而言，除了使用JSP自帶的經常使用標記外，不多開發本身的標記，或許Struts是一個很好的起點。 關於頁面導航，我認爲那將是從此的一個發展方向，事實上，這樣作，使系統的脈絡更加清晰。經過一個配置文件，便可把握整個系統各部分之間的聯繫，這對於後期的維護有着莫大的好處。尤爲是當另外一批開發者接手這個項目時，這種優點體現得更加明顯。 缺點： Taglib是Struts的一大優點，但對於初學者而言，卻須要一個持續學習的過程，甚至還會打亂你網頁編寫的習慣，可是，當你習慣了它時，你會以爲它真的很棒。 Struts將MVC的Controller一分爲三，在得到結構更加清晰的同時，也增長了系統的複雜度。 Struts從產生到如今還不到半年，但已逐步愈來愈多運用於商業軟件。雖然它如今還有很多缺點，但它是一種很是優秀的J2EE MVC實現方式，若是你的系統準備採用J2EE MVC架構，那麼，不妨考慮一下Struts。