轉載自：http://www.uml.org.cn/j2ee/200803315.asp
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層方法來完成功能。這樣便實現了業務代碼的分離，以及與前端框架的極大解耦。