問題的提出
我常常在思考一個問題，我們如何能設計出高水平、高質量的軟件出來。怎樣是高水平、高質量的軟件？它應當是易于維護、易于適應變更、可重用性好的一個系統。如何做到這一點呢？答案當然是“低耦合、高內聚”了。低耦合就是軟件在構造的時候，各個模塊、各個功能、各個類都不會過度依賴于它周圍的環境。只有這樣，才能使我們的模塊（功能、類）在周圍發生變更時不受影響，做到易于維護和易于適應變更。正因為如此，也使它更易于重用到其它功能類似的環境中，提高了重用性。高內聚則使軟件中的各個模塊（功能、類）能夠各盡其能而又充分合作，也就是對于軟件問題空間中需求的各個功能，系統可以合理地把它分配給各個模塊（功能、類）來共同完成，而不是一個或幾個八面玲瓏、包打天下的超級類一個人完成。而對于該系統中的某一個模塊（功能、類），具有自己高度相關的職責，即該職責中的幾個任務是高度相關的。每一個模塊（功能、類）都決不去完成與自己無關職責的任務。
那么怎樣能構造一個低耦合、高內聚的系統能，時下最流行的框架結構之一的struts+spring+hibernate然而我要說的是，即使我們使用了struts+spring+hibernate
分析與決策
1. 編寫DAO的時候不要直接去使用hibernate或spring對hibernate的支持。
現在我們在編寫DAO以上問題，究其原因，是我們項目中的DAO
2. 編寫Action的時候不要直接使用spring和spring的繼承類
前面我說了應當避免DAO的繼承類然后使用它的方法。如此的使用，我們的Action將依賴與spring。我們同樣可以使用一個叫BasicAction的父類，然后用一個接口來隔離spring。由于ActionBasicAction中，提高系統的可維護性。
3. 當BUS需要獲取別的模塊的數據的時候，不要直接去使用該模塊的DAO
我舉一個簡單的例子：我需要設計一個軟件評審的管理軟件，該軟件分為評審組織者制訂評審計劃、評審者分別填寫評審表后由評審組織者匯總評審表、評審組織者制作評審報告。這是一個非常簡單的項目，分成了三個人來完成。但是項目進行快結束的時候卻出現了問題。填寫評審表需要獲得評審計劃中的一些數據，制作評審報告的數據來源于評審表。項目組在開始編程前先開了一次會，大家約定好了各個部分的數據格式及其規則，然后開始工作。然而數天后項目組把各個模塊整合以后發現，系統根本跑不起來，為什么呢？設計評審計劃的人發現，所有評審計劃應當按照產品編號來進行管理而不是項目編號。由于這個變更，填寫評審表模塊在待評審列表中什么都無法顯示；同樣，設計評審表的人發現，在一個評審計劃中評審表與評審者不是一對多的關系，而是一對一的關系，因而修改了這兩個表的關聯。因為這樣，在制作評審報告時就不能正確得到評審表數據。其實一個軟件項目在整個進行過程中總是不斷變更。我們需要做的不是去抑制這些變更，而應當是通過軟件的結構去適應這些變更，即是降低各模塊間的依賴（耦合），提高內聚。
拿這個實例來說，當評審表需要調用評審計劃的數據的時候，不應當是自己寫一個DAO去調用評審計劃的數據，而應當是調用評審計劃的接口，將這個任務交給評審計劃類來完成。當評審報告需要調用評審表的數據的時候，同樣應當去調用評審表的接口，由評審表來實現。同時，這種調用應當是去調用BUS層的接口。為什么呢？比如在評審計劃中的一個業務邏輯是只有在評審計劃發布以后才能制作評審表，那么怎樣才是已發布的評審計劃呢？這個業務邏輯應當由誰來定義？當然是評審計劃。在什么地方定義？當然是BUS而不是DAO，因為DAO僅僅是實現數據的持久化，而BUS才是實現業務邏輯的地方。既然如此，如果評審表去調用評審計劃的DAO，那么已發布評審計劃的業務邏輯必然包含在了評審表的業務邏輯里了。我們假設有一天，已發布評審計劃的業務邏輯發生變更了（實際上這樣的會在你毫不經意間就發生了），編寫評審計劃的人會很快就修改了評審計劃的業務實現并且測試通過了。他不知道評審表里也包含了這樣的業務邏輯，因而修改后的程序在運行到評審表的時候就很可能會出錯。不幸的是，在實際工作中，同樣一個業務邏輯可能包含在無數個你可能知道，但你也可能不知道的代碼中。這樣的結構就是一個不易于維護的差的結構。
總結：從技術升級和需求變更兩方面適應變化
軟件開發專家Alistair Cockburn相關鏈接：回復：《如何在struts+spring+hibernate的框架下構建低耦合高內聚的軟件》。
| Spring-Hibernate.rar |
| 描述: |
|
下載 |
| 文件名: |
Spring-Hibernate.rar |
| 文件大小: |
9 KB |
| 下載過的: |
文件被下載或查看 511 次 |