例子1、銀行帳號Account：
一個(gè)經(jīng)常引起爭論的問題就是，deposit/draw方法到底應(yīng)該建模到 Account中還是建模到AccountManager(對一個(gè)銀行出納員的建模)中。
我覺的將deposit/draw建模到AccountManger中是反映現(xiàn)實(shí)的，因?yàn)锳ccount反映到現(xiàn)實(shí)世界就是一個(gè)沒有行為能力的實(shí)體，而出納員才具有行為能力。
例子2：選課的學(xué)生Student
對學(xué)生建模的時(shí)候，enroll(選課行為)毫無疑問應(yīng)該建模到類Student中。
除此之外，我們假設(shè)每個(gè)學(xué)生有一個(gè)考察級點(diǎn)，可以根據(jù)這個(gè)學(xué)生的表現(xiàn)增加或者減少級點(diǎn)，而我們就遇到同例1中提到的deposit/draw一樣的問題，就是增加級點(diǎn)的方法addScore/減少級點(diǎn)的方法reduceScore建模到Student中還是StudentManager中，個(gè)人認(rèn)為，同于例1，應(yīng)該建模到StudentManager中而不是Student中。

總的來說，方法到底建模到那個(gè)Class中，就根據(jù)這個(gè)方法是否是這個(gè)Class自發(fā)的行為。譬如，Account的deposit/draw就不應(yīng)該建模到Account中，但是實(shí)踐中，建模到Account中，往往會帶來一些好處，至于什么好處，Martin的《Domain Logic and SQL》非常全面的分析過了。所以，我感覺，Martin舉的例子中，貧血的Domain Model是亂扣大帽子。

本來就沒什么Transaction Script，沒什么貧血的Domain Model，Martin非要將一種正確的模型叫做“貧血的Domain Model"，而將沒有反映現(xiàn)實(shí)世界的、但是有一定實(shí)踐價(jià)值的模型起一個(gè)風(fēng)度翩翩的名字。

為什么有人經(jīng)常提到貧血的Domain Model？我覺的，可能很多應(yīng)用是以數(shù)據(jù)為中心的，所以，建模的時(shí)候，習(xí)慣性地思維定向到數(shù)據(jù)上，建模出來的類完全是DB Entity的反映。而正確的思路，應(yīng)該針對整個(gè)系統(tǒng)進(jìn)行對象建模，不要一開始就考慮持久化的問題。

轉(zhuǎn)載于:https://www.cnblogs.com/wildfish/archive/2005/03/22/123788.html

總結(jié)

以上是生活随笔為你收集整理的贫血的Domain Model之说的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。