基于SSH開發架構的重新分層
現代的企業開發中，越來越多地引入了多層架構設計模式。Struts+Spring+Hibernate (一下簡稱為SSH)就是其中之一，SSH架構是當前非?；鸬募軜?，很多金融、電信項目，大型門戶網站均選擇該架構作為業務支撐架構，開發流程也已經非常成熟。但是該結構開發起來，依舊存在一些問題。分析這些問題，得先從SSH架構的組成說起。
SSH為Struts+Spring+Hibernate的組成方式，Struts實現MVC，Spring負責架構的結合，Hibernate進行數據的持久化。通常其分層開發的結構圖(以一個業務新增為例)如下：
這樣的結構，滿足了一般的業務需要，但是對于當前日益復雜化的WEB2.0的開發，卻存在不少問題，歸納起來主要有以下幾點的不足：
A)DAO和服務層容易出現職責不明，由于按照MVC邏輯，業務代碼應該寫在Struts Action里，但是其事務的提供，卻是配置在Service層。為了一組在邏輯上完整的數據操作業務邏輯，需要涉及兩個層（Serveice、 Action）來進行編寫，遇到判斷的情況下，為了保證完整的事務操作，則需要將業務代碼移到Service層完成，而通常習慣了在Struts Action里調用多次Service而產生多個事務而在出現Exception時導致出錯時操作之前調用的Service事務的業務數據沒有回滾。
B)當需要返回的數據供AJAX使用，操作JSON或XML的的大量使用時。開發起來會很費力，一段同樣的業務代碼，為了使用AJAX和XML可能需要重新編寫一次，或者在同一個ACTION里通過標志來判斷，對分層結構造成了比較糟糕的破壞。如果設計得不好，為了使用JSON和XML還得額外增加大量的配置，嚴重降低了開發效率。
因此，為了克服這些缺點，本人對于SSH架構，進行了實現了重新的分層，共享了業務代碼。簡化了開發、增強了與AJAX技術、MXL技術的結合。提供了一種更高效的開發模式。
其開發的結構圖如下：
看到這個架構圖有人可能會問，Struts Action類的編寫去哪了呢？答案正是這個架構的優點，由于業務代碼統一實現IbusinessService接口，使得只需要相對固定的幾個 Struts Action類調用Service層的方法，便可以完成工作。包括JSON格式輸出，XML輸出及WebService輸出均調用Service層方法來完成功能。這樣便實現了業務代碼的分離，以及與前端框架的極大解耦。
原文鏈接：http://blog.csdn.net/hsttmht/article/details/7425099
【編輯推薦】
