|
前言:之前的文章,很多朋友發來了反饋,從反饋中也看出了一些問題,一個最明顯的問題就是:當我提到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就是過程化的設計方式，最直觀表現就是一個個的方法，每個方法做一個業務的流程。我們來看下面一個例子。例子的背景就是在電子商務網站中訂單的處理流程。
|
