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層方法來完成功能。這樣便實現了業務程式碼的分離，以及與前端框架的極大解耦。