前言:之前的文章,很多朋友發(fā)來了反饋,從反饋中也看出了一些問題,一個最明顯的問題就是:當(dāng)我提到DAL的實現(xiàn)的時候,一些朋友就問:DAL中采用了Repository模式嗎? 初一看起來,可能認(rèn)為這個問題沒有什么,其實仔細(xì)的想想就會發(fā)現(xiàn),確實在問題的背后隱藏的了另外的一個問題.

本篇的議題如下

1.問題的闡述

2.設(shè)計方法

3.總結(jié)

1.問題的闡述

在項目中,我們一般都是分層,大家最熟悉的就是UI,BLL,DAL層,或者在加上一個Services服務(wù)層.一般的項目就這樣設(shè)計了.由于越來越多的公司,社區(qū)倡導(dǎo)領(lǐng)域驅(qū)動設(shè)計(DDD),于是,又有了項目的分層的方式,DDD設(shè)計中的一些概念也引入了: Presentation, Service, Domain, Repository. 而且一般來說,有下面的對應(yīng)關(guān)系:

Presentation UI

Domain BLL

Repository DAL

但是在開發(fā)的時候,一會兒在項目中建立一個Domain的類庫,一會兒又在項目建立DAL,最后的情況就是:UI, Domain, DAL等等. 其實這倒是沒有什么,說到底只是一個名稱的問題,但是在只后面隱藏的問題就是:對DDD的不了解,很多的時候只是注重了”形”,而沒有領(lǐng)會到”神”.

在項目中不是建立了名稱為Presentation, Domain, Repository的類庫,這個項目就是DDD開發(fā)了,不是這樣的.本來在分層的時候采用UI,BLL,DAL,自己是很熟悉的,但是這樣一攪和, 最后反而把概念搞復(fù)雜了.

而且,在項目中,是采用原來樸實的那種三層,還是采用DDD開發(fā),是要經(jīng)過思考的,不是那DDD的方法來套.也就是說,不要為了DDD而DDD.就像當(dāng)初我們學(xué)習(xí)設(shè)計模式一樣,沒有必要在寫代碼的過程中為了設(shè)計模式而設(shè)計模式.

2.設(shè)計方法

到底是采用DDD還是那種樸實的三層,主要取決與業(yè)務(wù)層的設(shè)計和系統(tǒng)的復(fù)雜度.

如果系統(tǒng)確實很復(fù)雜,業(yè)務(wù)邏輯相當(dāng)?shù)膹?fù)雜,那么建議采用DDD,因為DDD的引入就是用解決復(fù)雜性的.因為采用DDD的方法來設(shè)計業(yè)務(wù)邏輯層,那么業(yè)務(wù)邏輯層就只是關(guān)注業(yè)務(wù)邏輯的處理,至于怎么存儲和獲取數(shù)據(jù),絲毫不關(guān)心,所以基于這個原因,在DDD中就引入了Repository的概念,Repository就是來輔助業(yè)務(wù)邏輯層處理數(shù)據(jù)的.

雖然我一直在提”樸實的三層”,其實DDD和它之間沒有什么很明顯的劃分了,這里我之所以特意的把他們劃分出來,主要就是因為我們在項目開發(fā)中一般是三層(或者N層),這里提出主要是為便于后面講述一些問題.

下面就開始講述一些業(yè)務(wù)邏輯層設(shè)計方法,相信大家看完之后,很多的疑惑就迎刃而解了.

業(yè)務(wù)層的設(shè)計方法有三種:Transaction Script, Active Record和Domain Model.

看過Flower的<<企業(yè)架構(gòu)模式>>一書的朋友應(yīng)該對上面的三個詞語很熟悉,在書中,這些概念講的確實很精煉,可能因為精煉,所以理解起來就不是很容易.

在本篇文章中,就涉及到了這些知識,只有把這些點講清楚了,之前的問題就能解決.

如果熟悉這些概念的朋友,也不妨看看,大家可以交流!

首先來看看Transaction Script(之所以沒有翻譯為中文，因為翻譯后的中文意思很容易讓人產(chǎn)生誤導(dǎo))

其實Transaction Script就是過程化的設(shè)計方式，最直觀表現(xiàn)就是一個個的方法，每個方法做一個業(yè)務(wù)的流程。我們來看下面一個例子。例子的背景就是在電子商務(wù)網(wǎng)站中訂單的處理流程。