《如何在struts+spring+hibernate的架構下構建低耦合高內聚的軟體》

標籤：名稱   好的   異常   顯示   mvc   職責   style   計劃   查詢條件   

　　問題的提出我常常在思考一個問題，我們如何能設計出高水平、高品質的軟體出來。怎樣是高水平、高品質的軟體？它應當是易於維護、易於適應變更、可重用性好的一個系統。如何做到這一點呢？答案當然是“低耦合、高內聚”了。低耦合就是軟體在構造的時候，各個模組、各個功能、各個類都不會過度依賴於它周圍的環境。只有這樣，才能使我們的模組（功能、類）在周圍發生變更時不受影響，做到易於維護和易於適應變更。正因為如此，也使它更易於重用到其它功能類似的環境中，提高了重用性。高內聚則使軟體中的各個模組（功能、類）能夠各盡其能而又充分合作，也就是對於軟體問題空間中需求的各個功能，系統可以合理地把它分配給各個模組（功能、類）來共同完成，而不是一個或幾個八面玲瓏、包打天下的超級類一個人完成。而對於該系統中的某一個模組（功能、類），具有自己高度相關的職責，即該職責中的幾個任務是高度相關的。每一個模組（功能、類）都決不去完成與自己無關職責的任務。

　　那麼怎樣能構造一個低耦合、高內聚的系統能，時下最流行的架構結構之一的struts+spring+hibernate為我們提供了方便。使用struts我們可以應用MVC模型，使頁面展現與商務邏輯分離，做到了頁面展現與商務邏輯的低耦合。當我們的頁面展現需要變更時，我們只需要修改我們的頁面，而不影響我們的商務邏輯；同樣，我們的商務邏輯需要變更的時候，我們只需要修改我們的java程式，與我們的頁面無關。使用spring我們運用IoC（反向控制），降低了商務邏輯中各個類的相互依賴。假如類A因為需要功能F而調用類B，在通常的情況下類A需要引用類B，因而類A就依賴於類B了，也就是說當類B不存在的時候類A就無法使用了。使用了IoC，類A調用的僅僅是實現了功能F的介面的某個類，這個類可能是類B，也可能是另一個類C，由spring的設定檔來決定。這樣，類A就不再依賴於類B了，耦合度降低，重用性提高了。使用hibernate則是使我們的商務邏輯與資料持久化分離，也就是與將資料存放區到資料庫的操作分離。我們在商務邏輯中只需要將資料放到值對象中，然後交給hibernate，或者從hibernate那裡得到值對象。至於用Oracle、MySQL還是SQL Server，如何執行的操作，與我無關。

然而我要說的是，即使我們使用了struts+spring+hibernate架構構建我們的軟體，就可以做到“低耦合、高內聚”了嗎？我認為這是遠遠不夠的！我認為我們在使用struts+spring+hibernate架構的時候常常會有以下幾個問題值得改進。

分析與決策
　　

1.編寫DAO的時候不要直接去使用hibernate或spring對hibernate的支援。 
　　現在我們在編寫DAO的時候普遍都是直接繼承spring對hibernate的封裝類HibernateDaoSupport，然後使用該類提供的諸如saveOrUpdate(), saveOrUpdateCopy(), find()等等。另外，在使用excute()方法實現一些更複雜的hibernate功能的時候還會使用hibernate的類，諸如Query, Session, Type等。這樣直接使用spring和hibernate的類存在的問題在於，你的代碼將不得不依賴與spring和hibernate的某個版本。比如說，現在hibernate3出來了，改動挺大，實際上最要命的是包結構，hibernate2的包結構是net.sf.hibernate.*，然而hibernate3是org.hibernate.*。同樣，spring為了支援hibernate3，包名也改為org.springframework.orm.hibernate3.*。假如，你現在新開發一個項目，這沒什麼關係，如果是升級一個項目問題就來了。如果你希望將你的一個項目從hibernate2升級為hibernate3，你不得不修改DAO中所有對hibernate和spring-hibernate的引用。如果你的代碼中出現hibernate2與hibernate3不相容的方法和類，比如saveOrUpdateCopy()（在hibernate3中已經沒有了）,你還將不得不改寫。那麼你可能會說，我不會這樣升級。如果你的軟體生命週期有好多年，hibernate升級到4，升級到5，你還是依然使用hibernate2？如果你以這種方式開發一個平台，你能要求所有使用你平台的軟體項目都只能使用hibernate2？更進一步說，我現在開發一個產品，今後的客戶將是成千上萬。經過1、2年我需要升級了，這時我的升級包有幾十M，幾乎把所有的DAO都換了個遍，這樣的升級無異於重裝。也許，有人會提出另一個方案，在HibernateDaoSupport與DAO中間增加了一個基礎類，這樣將基礎類中的org.springframework.orm.hibernate.support.HibernateDaoSupport，改為了org.springframework.orm.hibernate3.support.HibernateDaoSupport，這樣其下面繼承的DAO就不用改動了。然而在源碼上是小小的改動，但對於類來說，兩個不同版本的HibernateDaoSupport其相關的屬性和方法還是有不少變化，那麼在基礎類重新編譯的同時，你的繼承類重新編譯否。既然已經重新編譯了，因此你的所有DAO在升級的時候依然要打入升級包，問題依然存在。

　　以上問題，究其原因，是我們項目中的DAO依賴於hibernate和spring，因為我們對它們的使用是繼承，是一種很強的關聯，就是一種依賴。我們只需要稍微進行一些調整，就可以解決這個問題，那就是不使用直接繼承，而使用介面進行分離。可以使用Facade模式，先建立一個叫BasicDao的基礎類，從名稱我們可以看出，它是所有DAO的基礎類，實現DAO操作所需的所有諸如save()、delete()、load()、query()等方法，除了一些基本的方法，諸如翻頁查詢、getCount、解析查詢條件形成HQL語句等功能也在這裡實現，但是不要使用與hibernate或spring有關的任何方法和類。同時，BasicDao調用一個叫DaoSupport的介面，DaoSupport的介面則是提供持久化所需的基本方法，最原始的元素。然後，我為DaoSupport介面提供各種不同的實現，比如hibernate2的實現DaoSupportHibernateImp、hibernate3的實現DaoSupportHibernate3Imp，整個結構如所示。BasicDao可以使用hibernate或spring提供的方法，但是不是直接使用，而是通過調用DaoSupport的實作類別來使用。然而BasicDao到底是使用的那個實作類別，我們通過spring的IoC，通過設定檔來決定到底使用哪個實現。同時，BasicDao也不要使用諸如SpringContext的類來實現IoC，而是通過建立setDaoSupport()和getDaoSupport()方法，然後在spring設定檔中建立引用。

2.編寫Action的時候不要直接使用spring和spring的繼承類 

　　前面我說了應當避免DAO引用spring或hibernate及其繼承類。同樣的事情也發生在Action中。由於Action通常不納入spring的管理，因此Action在通過spring調用某個BUS的時候，往往是去引用一個叫SpringContext的類（spring的類ContextLoaderServlet的繼承類），然後使用它的getBean()方法。如此的使用，我們的Action將依賴於spring。我們同樣可以使用一個叫BasicAction的父類，然後用一個介面來隔離spring。由於Action通常不納入spring的管理，我們通過一個*.property的設定檔來決定介面到底調用哪個實作類別。這樣的結構的另一個好處是，我們還可以將所有Action都必須使用的諸如寫日誌、使用者校正、異常處理都放在父類BasicAction中，提高系統的可維護性。

3.當BUS需要擷取別的模組的資料的時候，不要直接去使用該模組的DAO

　　我舉一個簡單的例子：我需要設計一個軟體評審的管理軟體，該軟體分為評審召集人制訂評審計劃、評審者分別填寫評審表後由評審召集人匯總評審表、評審召集人製作評審報告。這是一個非常簡單的項目，分成了三個人來完成。但是項目進行快結束的時候卻出現了問題。填寫評審表需要獲得評審計劃中的一些資料，製作評審報告的資料來源於評審表。項目組在開始編程前先開了一次會，大家約定好了各個部分的資料格式及其規則，然後開始工作。然而數天后項目組把各個模組整合以後發現，系統根本跑不起來，為什麼呢？設計評審計劃的人發現，所有評審計劃應當按照產品編號來進行管理而不是項目編號。由於這個變更，填寫評審表模組在待評審列表中什麼都無法顯示；同樣，設計評審表的人發現，在一個評審計劃中評審表與評審者不是一對多的關係，而是一對一的關係，因而修改了這兩個表的關聯。因為這樣，在製作評審報告時就不能正確得到評審表資料。其實一個軟體項目在整個進行過程中總是不斷變更。我們需要做的不是去抑制這些變更，而應當是通過軟體的結構去適應這些變更，即是降低各模組間的依賴（耦合），提高內聚。

　　拿這個執行個體來說，當評審表需要調用評審計劃的資料的時候，不應當是自己寫一個DAO去調用評審計劃的資料，而應當是調用評審計劃的介面，將這個任務交給評審計劃類來完成。當評審報告需要調用評審表的資料的時候，同樣應當去調用評審表的介面，由評審表來實現。同時，這種調用應當是去調用BUS層的介面。為什麼呢？比如在評審計劃中的一個商務邏輯是只有在評審計劃發布以後才能製作評審表，那麼怎樣才是發行的評審計劃呢？這個商務邏輯應當由誰來定義？當然是評審計劃。在什麼地方定義？當然是BUS而不是DAO，因為DAO僅僅是實現資料的持久化，而BUS才是實現商務邏輯的地方。既然如此，如果評審表去調用評審計劃的DAO，那麼發行評審計劃的商務邏輯必然包含在了評審表的商務邏輯裡了。我們假設有一天，發行評審計劃的商務邏輯發生變更了（實際上這樣的會在你毫不經意間就發生了），編寫評審計劃的人會很快就修改了評審計劃的業務實現並且測試通過了。他不知道評審表裡也包含了這樣的商務邏輯，因而修改後的程式在運行到評審表的時候就很可能會出錯。不幸的是，在實際工作中，同樣一個商務邏輯可能包含在無數個你可能知道，但你也可能不知道的代碼中。這樣的結構就是一個不易於維護的差的結構。

　　

　　總結：從技術升級和需求變更兩方面適應變化軟體開發專家Alistair Cockburn在《敏捷式軟體開發 (Agile Software Development)》中說過，軟體在整個生命週期中變更是無時無刻不發生的。我認為，軟體的變更一方面是技術的更新，今天我們使用struts+spring+hibernate，明天呢，我們將使用什麼呢？正因為技術變更得太快，我們的系統應當不要太依賴於某個具體的技術或架構，以便於明天的技術更新。同時，來自客戶的需求變更也是我們必須面對的另一個壓力。一句經典的話是這樣描述客戶的變更：“當我看到時我的需求就變更了。（I changed just when I saw it.）”過去我們用需求說明書來抑制使用者的變更，現在發現不能這樣了。敏捷式軟體開發 (Agile Software Development)提出了許多應對使用者變更的辦法，其中建立低耦合高內聚的軟體結構也是辦法之一。系統中的所有對象都有自己的明確職責，這個職責應當不多且高度相關。每個對象都應當只完成自己的職責，而把其它的任務交給別人去做。正如我前面提到的例子，評審表對象只完成與評審表相關的操作，而在它需要完成的任務中，需要使用評審計劃資料的相關功能，交給評審計劃對象去完成，評審表只管調用。這樣的構造要求開發人員相互協調，彼此多交流，同時，也需要有人來統一規劃，站在全域的設計這個系統。通過這些，我們才可以適應變化，提高設計水平

《如何在struts+spring+hibernate的架構下構建低耦合高內聚的軟體》