|
Domain Model對于大多數(shù)的人來說都不怎么的陌生，Domain Model作為實現(xiàn)業(yè)務(wù)層的兩種重要方法之一，在PoEAA(企業(yè)應(yīng)用架構(gòu)模式)中得到Martin Fowler的大力推廣，但個人覺得在Domain Model上的應(yīng)用并不是那么的理想，這個還得從業(yè)務(wù)層實現(xiàn)的兩種模式談起，分別為Domain Model和Transaction Script，Domain Model的原則為采用Domain Object的方式來實現(xiàn)業(yè)務(wù)邏輯，使得業(yè)務(wù)邏輯得以聚合到對象本身，從本質(zhì)上提升業(yè)務(wù)對象的可復(fù)用性，其優(yōu)點就在于提升了業(yè)務(wù)對象的復(fù)用性和代碼的整潔性，缺點則在于實現(xiàn)的難度較高，有一定的學(xué)習(xí)曲線；Transaction Script則為采用Script的方式編排業(yè)務(wù)邏輯，其優(yōu)點在于實現(xiàn)起來簡單，缺點在于代碼中出現(xiàn)較多重復(fù)的業(yè)務(wù)邏輯塊，在業(yè)務(wù)邏輯一旦變動時需要修改很多地方，降低了業(yè)務(wù)邏輯的復(fù)用性。 其實個人看法是Domain Model為采用OO構(gòu)成業(yè)務(wù)層模型的思想，而Transaction Script為采用面向過程構(gòu)成業(yè)務(wù)層模型的思想。 從需求分析開始談起，在對需求進(jìn)行OOA后，產(chǎn)生出系統(tǒng)的業(yè)務(wù)模型，通過OOD得到業(yè)務(wù)模型技術(shù)體系，那么在Domain Model很簡單的就是將此業(yè)務(wù)模型技術(shù)體系進(jìn)行Plain Object的實現(xiàn)，從此得到Domain Object，按照這樣的邏輯Transaction Script其實是不應(yīng)該會出現(xiàn)的，Transaction Script的產(chǎn)生當(dāng)然是有它的原因的，在復(fù)雜的業(yè)務(wù)場景中需要通過多個Domain Object共同來完成業(yè)務(wù)功能的實現(xiàn)，而此時在設(shè)計不夠良好的Domain Object模型的情況下很難通過Domain Object的協(xié)作來做到實現(xiàn)，需要在Domain Object的協(xié)作之外處理一些業(yè)務(wù)邏輯，這個時候Transaction Script就得以出現(xiàn)了，以Script的方式來協(xié)作Domain Object并同時補充其中的業(yè)務(wù)邏輯來完成業(yè)務(wù)功能的實現(xiàn)，其實這個時候已經(jīng)可以看到，實現(xiàn)的方式確實是變簡單了，但業(yè)務(wù)模型則被逐漸的拆離，在Domain Model中則強調(diào)Domain Object本身業(yè)務(wù)邏輯的實現(xiàn)，而業(yè)務(wù)層則通過引入一層薄Service作為對外的接口來提供業(yè)務(wù)場景的實現(xiàn)，此時的Service需要做的是調(diào)用Domain Object來完成業(yè)務(wù)場景的實現(xiàn)。 Domain Object對應(yīng)到業(yè)務(wù)模型，在結(jié)合了持久層來完成相應(yīng)業(yè)務(wù)Object的持久，個人覺得ORM的引入在這部分使得Domain Object在需要完成持久的時候更加的優(yōu)秀，Domain Object中通過注釋標(biāo)識出需要持久的屬性，當(dāng)然這是因為ORM工具需要通過這些映射來處理，這樣在對Domain Object作持久操作時可直接的進(jìn)行，這樣的Domain Object就構(gòu)成了系統(tǒng)的核心部分，業(yè)務(wù)模型構(gòu)成系統(tǒng)的核心模型，這是需求符合體現(xiàn)的關(guān)鍵。 至于View Object則由于其簡單性很多時候必須構(gòu)建，以保持View Layer的單一性以及只是View的性質(zhì)。 |
|
|
