原文
關于"貧血模型"的討論幾乎沒有停止過,在openfans.org的開發過程中,我們也討論了很久,我覺的有很多東西應該記下來:
明確一下意思先:
DAO:數據操作對象,會操作數據庫
持久層:能提供對象持久化服務的一系列組件或服務
領域對象:描述領域模型的對象,是通過業務分析進行系統建模的產物
貧
血模型:就是domain
object只有屬性的getter/setter方法的純數據類，所有的業務邏輯完全由一個所謂的Manager來完成(又稱
TransactionScript)，這種模型下的domain object被Martin Fowler稱之為“貧血的domain
object”
常見的類基本結構如下:
一個業務數據類叫做Item，
一個DAO接口類叫做ItemDao
一個DAO接口實現類叫做ItemDaoHibernateImpl
一個業務邏輯類叫做ItemManager(或者叫做ItemService).
觀察上面的幾個類很容易發現問題:
1:Item和ItemManager實際是操作與數據的關系,實際完成的就是經典OO中的一個對象的能力;
2:當有許多Item時 類組變得很龐大,產生很多 xxxDao xxxImpl xxxManager 其中包含大量重復代碼;
按<<重構>>的觀點,上述代碼存在以下臭味:
1:重復的代碼?? xxxDao xxxImpl xxxManager(通常)
2:霰彈式修改，一個變化影響多個類,類之間不夠高內聚 item變化-->Dao,Impl,Manager均要變動
3:依戀情結,兩個類之間互相作用過多 item<->Manager
4:平行繼承體系,當增加一個新類時總是要增加另一個類
5:夸夸其談未來性,在沒有任何暗示的情況下考慮擴展? Dao,實際HibernateImpl可能n年內是唯一的Dao實現
6:純稚的數據類，只有數據的類? item
我覺的 貧血模型 是系統分析設計方向性錯誤的產物:
1:沒有進行領域建模---以數據表結構為中心,而不是業務模型為中心的思考方式,使設計人員選擇Item為考慮問題的出發點
2:將DAO與持久層混淆---我們需要的一種持久化服務,DAO緊緊是提供數據操作能力而已,Hibernate是一種高級的服務(他已經包含了DAO,而不是相反),已經完成了所有的持久層服務.
3:過于強調低偶合---將一些本來一些提供單一職責的內容分散在多個單元中使 客戶端 依賴更多的接口,而忘記了高內聚原則.
4:Spring的能力限制---由于Spring現階段不支持對于領域模型的服務注入,使設計人員將操作和數據分開,并將領域變為DataOnly的.
? (Spring2.0將在很大程度上解決這個問題)
?
我認為良好的解決方案:
? 首先領域建模,建立領域模型-->合并前面所說的Item和ItemManager成為 domainItem;對于數據庫服務,
? 1:如果考慮領域層包含數據操作能力,則建立DAO并選擇其它好的DAO方案比如IBATIS或Hibernate之類的組件;
? 2:如果考慮將數據庫(或其他存儲界質)存儲考慮在領域之外成為持久層,
? ??? a:則或者對持久層框架同時建模,同時選擇合適的組件為持久層服務提供存儲服務(包括DAO--亦可選擇IBATIS/Hibernate組件),
? ??? b:或者直接使用Hibernate/JDO等框架實現持久化服務,領域層直接使用持久層服務,對領域對象進行持久化和反持久化(從持久層獲取以持久化的對象).
?
其他:
?
實際上,作為一種解決方案,所謂"貧血模型"的具體使用,并不會有太大的問題,尤其是使用一些代碼生成工具或已經做好相應的基本框架時,很多軟件的核心價
值都在于對客戶提供的服務,而其內部則成為黑盒,我們只要合理的解決業務問題,就是"王道"了,對于代碼的臭味,可以慢慢重構--這也需要成本呀.?
?
再其他:
有人說,我們的業務就是CRUD,領域模型只有數據類就足夠了.我覺的這是搞錯了方向------只有CRUD時,只有處理CRUD的那些類才有必要進行建模(他們才是領域模型),而所謂的User\Item等數據類則完全沒有必要進行建模,更不要談領域了.
貧血之外:
實際上,軟件\OO方法的外延大的很,更多問題與數據庫存儲無關(但也有貧血問題),所以建模才是根本,OO方法的原則才是我們必須掌握的.