現代的企業開發中,越來越多地引入了多層架構設計模式.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層方法來完成功能.這樣便實現了業務代碼的分離,以及與前端框架的極大解耦.
