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

本篇的議題如下

1.問題的闡述

2.設計方法

3.總結

1.問題的闡述

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

Presentation UI

Domain BLL

Repository DAL

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

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

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

2.設計方法

到底是采用DDD還是那種樸實的三層,主要取決與業務層的設計和系統的復雜度.

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

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

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

業務層的設計方法有三種:Transaction Script, Active Record和Domain Model.

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

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

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

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

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