Martin Fowler很早以前就寫過一篇文章,題目叫"貧血模型"。文章里面批判貧血的領(lǐng)域模型是不夠優(yōu)雅、不夠OO的,提倡使用充血的領(lǐng)域模型。在Java世界里這是一直爭(zhēng)論的話題。到底什么是貧血什么是充血呢?
貧血模型:是指領(lǐng)域?qū)ο罄镏挥術(shù)et和set方法,或者包含少量的CRUD方法,所有的業(yè)務(wù)邏輯都不包含在內(nèi)而是放在Business Logic層。
優(yōu)點(diǎn)是系統(tǒng)的層次結(jié)構(gòu)清楚,各層之間單向依賴,Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。當(dāng)然Business Logic是依賴Domain Object的。似乎現(xiàn)在流行的架構(gòu)就是這樣,當(dāng)然層次還可以細(xì)分。
該模型的缺點(diǎn)是不夠面向?qū)ο螅I(lǐng)域?qū)ο笾皇亲鳛楸4鏍顟B(tài)或者傳遞狀態(tài)使用,所以就說只有數(shù)據(jù)沒有行為的對(duì)象不是真正的對(duì)象。在Business Logic里面處理所有的業(yè)務(wù)邏輯,在POEAA(企業(yè)應(yīng)用架構(gòu)模式)一書中被稱為Transaction Script模式。
充血模型:層次結(jié)構(gòu)和上面的差不多,不過大多業(yè)務(wù)邏輯和持久化放在Domain Object里面,Business Logic只是簡(jiǎn)單封裝部分業(yè)務(wù)邏輯以及控制事務(wù)、權(quán)限等,這樣層次結(jié)構(gòu)就變成Client->(Business Facade)->Business Logic->Domain Object->Data Access。
優(yōu)點(diǎn)是面向?qū)ο?,Business Logic符合單一職責(zé),不像在貧血模型里面那樣包含所有的業(yè)務(wù)邏輯太過沉重。
缺點(diǎn)是如何劃分業(yè)務(wù)邏輯,什么樣的邏輯應(yīng)該放在Domain Object中,什么樣的業(yè)務(wù)邏輯應(yīng)該放在Business Logic中,這是很含糊的。即使劃分好了業(yè)務(wù)邏輯,由于分散在Business Logic和Domain Object層中,不能更好的分模塊開發(fā)。熟悉業(yè)務(wù)邏輯的開發(fā)人員需要滲透到Domain Logic中去,而在Domian Logic又包含了持久化,對(duì)于開發(fā)者來說這十分混亂。 其次,因?yàn)锽usiness Logic要控制事務(wù)并且為上層提供一個(gè)統(tǒng)一的服務(wù)調(diào)用入口點(diǎn),它就必須把在Domain Logic里實(shí)現(xiàn)的業(yè)務(wù)邏輯全部重新包裝一遍,完全屬于重復(fù)勞動(dòng)。
聯(lián)系客服