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

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

本篇的議題如下

1.問題的闡述

2.設計方法

3.總結

1.問題的闡述

在項目中，我們一般都是分層，大家最熟悉的就是UI，BLL，DAL層，或者在加上一個Services服務層。一般的項目就這樣設計了。由于越來越多的公司，社區倡導領域驅動設計，于是，又有了項目的分層的方式，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和它之間沒有什么很明顯的劃分了，這里我之所以特意的把他們劃分出來，主要就是因為我們在項目開發中一般是三層，這里提出主要是為便于后面講述一些問題。

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

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

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

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

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

首先來看看Transaction Script

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

  Tag: 設計公司 | 網頁設計公司 | 廣告公司 | 網站設計 | 平面設計 | 互動媒體 | 網頁設計 | Web design | Website design | design house | 媒體公司 | Iphone app | 程式設計 | Flash 網頁 | Flash game | 動畫設計 | 後期製作 | 網上商店 | 網上宣傳 | 網頁服務 |