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