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

本篇的議題如下:

1.  問(wèn)題的闡述

2. 設(shè)計(jì)方法

3.  總結(jié)

1.  問(wèn)題的闡述

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

但是在開(kāi)發(fā)的時(shí)候,一會(huì)兒在項(xiàng)目中建立一個(gè)Domain的類(lèi)庫(kù),一會(huì)兒又在項(xiàng)目建立DAL,***的情況就是:UI, Domain, DAL等等. 其實(shí)這倒是沒(méi)有什么,說(shuō)到底只是一個(gè)名稱(chēng)的問(wèn)題,但是在只后面隱藏的問(wèn)題就是:對(duì)DDD的不了解,很多的時(shí)候只是注重了”形”,而沒(méi)有領(lǐng)會(huì)到”神”.

在項(xiàng)目中不是建立了名稱(chēng)為Presentation, Domain, Repository的類(lèi)庫(kù),這個(gè)項(xiàng)目就是DDD開(kāi)發(fā)了,不是這樣的.本來(lái)在分層的時(shí)候采用UI,BLL,DAL,自己是很熟悉的,但是這樣一攪和, ***反而把概念搞復(fù)雜了.

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

2.  設(shè)計(jì)方法

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

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

雖然我一直在提”樸實(shí)的三層”,其實(shí)DDD和它之間沒(méi)有什么很明顯的劃分了,這里我之所以特意的把他們劃分出來(lái),主要就是因?yàn)槲覀冊(cè)陧?xiàng)目開(kāi)發(fā)中一般是三層(或者N層),這里提出主要是為便于后面講述一些問(wèn)題.

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

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

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

在本篇文章中,就涉及到了這些知識(shí),只有把這些點(diǎn)講清楚了,之前的問(wèn)題就能解決.

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

首先來(lái)看看Transaction Script(之所以沒(méi)有翻譯為中文，因?yàn)榉g后的中文意思很容易讓人產(chǎn)生誤導(dǎo))

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

public class OrderManager  
    {  
        public void PlaceOrder(OrderDTO order)  
        {  
            // Validate order based on business rules  
            // Check for stock availablity on items ordered  
            // Add the order to the database  
            // Set the order id on the OrderDTO object  
        }  
        public bool CancelOrder(Guid orderId)  
        {  
            // Retrieve order from database  
            // Determine if the order can be canceled  
            // if order can be canceled, set as canceled  
            // return true/false if order was canceled  
        }  
        public bool AddItemToOrder(Guid orderId, OrderItemDTO ItemToAdd)  
        {  
            // Retrieve order from database  
            // Determine if the item can be added to the order  
            // Add a new item row in the database  
            // return true/false if item was added to the order  
        }  
        public bool ProcessOrder(Guid orderId)  
        {  
            // Check to ensure this order can be processed.  
            // Validate order based on business rules  
            // Update the stock levels of products ordered  
            // return true/false if order was processed  
        }  
    } 

在上面的代碼中，所有和訂單處理有關(guān)的邏輯都寫(xiě)在OrderManager類(lèi)中。類(lèi)中的每一個(gè)方法就對(duì)應(yīng)業(yè)務(wù)邏輯中的一個(gè)流程或者說(shuō)對(duì)應(yīng)一個(gè)use case，例如：CancelOrder就是取消訂單。

通過(guò)Transaction Script的方式來(lái)組織業(yè)務(wù)邏輯，一個(gè)很好的好處就是直觀，很容易理解代碼在做什么。如果有新的流程來(lái)了，再加一個(gè)方法就行了。

同時(shí)，這種組織方式的弊端就在于，當(dāng)系統(tǒng)中的業(yè)務(wù)變得多而且復(fù)雜的時(shí)候，那么這樣的方法就開(kāi)始變多，***的結(jié)果就是一個(gè)類(lèi)中有成百上千個(gè)方法。而且這些方法中，除了一些基本的驗(yàn)證可以提取為方法重用，其他的流程控制代碼在很多的地方要重寫(xiě)，特別是當(dāng)有兩個(gè)流程差不多的時(shí)候，代碼不可避免的重新寫(xiě)。于是，這樣的類(lèi)開(kāi)始變得龐大而難以管理。

Active Record

這種組織方式已經(jīng)是我們最熟悉的了。

在很多的項(xiàng)目中，我們的業(yè)務(wù)實(shí)體類(lèi)基本和數(shù)據(jù)庫(kù)中表是一一對(duì)應(yīng)的，例如一個(gè)Order業(yè)務(wù)類(lèi)就是代表了數(shù)據(jù)庫(kù)中的Order表。而且在平時(shí)項(xiàng)目中，”樸實(shí)的三層(N層)”，一般都是基于這種方式在組織邏輯。

這種方式的***的區(qū)別就是每個(gè)業(yè)務(wù)類(lèi)自己負(fù)責(zé)自己的數(shù)據(jù)存取，也就是說(shuō)在業(yè)務(wù)類(lèi)中包含了業(yè)務(wù)邏輯的處理和數(shù)據(jù)的存取。

例如：

public class Order  
{  
    private Guid _id;  
    private DateTime _creationDate;  
    private int _shippingMethod;  
    private int _status;  
    private List<OrderItems> _orderItems;  
    public Guid Id  
    {  
        get { return _id; }  
        set { _id = value; }  
    }  
 
    public List<OrderItems> OrderItems  
    {  
        get { return _orderItems; }  
        set { _orderItems = value; }  
    }  
    // Business Logic  
    public void Place()  
    {  
        // Validate order based on business rules to ensure it is in  
        // a good state to add to the database  
        // Check for stock availablity on items ordered  
        this.Add();  
    }  
    public void Cancel()  
    {  
        // Check to ensure this order can be canceled.  
        this.Status = Status.Cancelled();  
        this.Save();  
    }  
 
    public void ProcessOrder()  
    {  
        // Check to ensure this order can be processed.  
        // Validate order based on business rules  
        // Udpate the stock levels of products ordered  
    }  
 
    // Data Access Methods  
    public void Save()  
    {  
        // Code to persist changes to the database  
    }  
 
    public void Add()  
    {  
        // Code to Add this object to the database  
    }  
 
    public void Delete()  
    {  
        // Code to remove this object from the database  
    }  
 
    public static List<Order> FindAll()  
    {  
        // Code to retrive all Orders from the database  
    }  
    public static Order FindBy(Guid id)  
    {  
        // Code to retrive a specific Order from the database  
    }  
} 

上面的代碼中，Order類(lèi)包含了業(yè)務(wù)邏輯處理的代碼，如Cancel, Process。通過(guò)這些方法也調(diào)用了數(shù)據(jù)訪問(wèn)代碼來(lái)保存數(shù)據(jù)。

如果在開(kāi)發(fā)的項(xiàng)目中，業(yè)務(wù)類(lèi)和數(shù)據(jù)表是一一對(duì)應(yīng)的關(guān)系，例如在開(kāi)發(fā)博客或者論壇，Active Record方式就很合適。

相信很多的項(xiàng)目都是基于這個(gè)方式在開(kāi)發(fā)和組織邏輯層，這個(gè)方式***的弊端就是：數(shù)據(jù)庫(kù)表只要改動(dòng)，那么業(yè)務(wù)邏輯層動(dòng)，而且這種變動(dòng)會(huì)一直波及到了UI那端。

Domain Model

通過(guò)用這種方式來(lái)組織業(yè)務(wù)層的時(shí)候，業(yè)務(wù)層就只是關(guān)注把現(xiàn)實(shí)中的概念轉(zhuǎn)換為相應(yīng)的業(yè)務(wù)邏輯模型，不關(guān)注其他的方面。例如，在電子商務(wù)網(wǎng)站開(kāi)發(fā)中，一些概念就被建模表示為一個(gè)個(gè)的業(yè)務(wù)模型(也就是業(yè)務(wù)類(lèi))，Order, Shopping Cart, Customer等。而且和Active Record***的區(qū)別就是：Domain Model中的業(yè)務(wù)類(lèi)不是和表一一對(duì)應(yīng)的，下圖就是一個(gè)很好的例子：

而且最主要的特點(diǎn)就是：每個(gè)業(yè)務(wù)類(lèi)包含了很多的業(yè)務(wù)驗(yàn)證，狀態(tài)跟蹤等。職責(zé)很單一，便于維護(hù)和理解。

示例代碼如下：

public class Order  
{  
    private Guid _id;  
 
    public Guid Id  
    {  
        get { return _id; }  
        set { _id = value; }  
    }  
 
    public float ShippingCost()  
    {  
        return ShippingMethod.ShippingCostTo(this.DispatchAddress, this.ItemsTotalWeight());  
    }  
 
    public float Total()  
    {  
        return DiscountOffer.TotalPriceWithDiscountOfferAppliedTo(  
        this.Items, ShippingCost());  
    }  
 
    public void Process()  
    {  
        if (this.CanProcess())  
        {  
        // Charge the card  
        Customer.Card.Charge(this.Total());  
        // Set the status of the order  
        this.Status = Status.Shipped;  
        // Adjust the stock levels  
        foreach (OrderItem item in Items)  
        {  
            item.Product.DecreaseStockBy(item.QtyOrdered);           
        }  
        else 
        {  
            throw new InvalidOrderStateForOperationException(  
            String.Format(  
            "Order {0} cannot be processed in its current state {1}",  
            this.Id, this.Status.ToString());  
        }  
    }  
 
    public bool CanProcess()  
    {  
        if (!this.Status == Status.Shipped && !this.Status = Status.Cancelled)  
        {  
            return (this.HasEnoughStockFor(me.Items) &&  
 
            GetBrokenRules.Count() == 0);  
        }  
        else 
        {  
            return false;  
        }  
    }  
 
    public List<BrokenBusinessRule> GetBrokenRules()  
    {  
        List<BrokenBusinessRule> brokenRules = new List<BrokenBusinessRule>();  
        if (Customer == null)  
            brokenRules.Add(new BrokenBusinessRule()  
            {  
                Property = "Customer",  
                Rule = "An Order must have a Customer" 
            });  
        else if (Customer.GetBrokenRules().Count > 0)  
        {  
            AddToBrokenRulesList(brokenRules, Customer.GetBrokenRules());  
        }  
        if (DispatchAddress == null)  
            brokenRules.Add(new BrokenBusinessRule()  
            {  
                Property = "DispatchAddress",  
                Rule = "An Order must have a Dispatch Address" 
            });  
        else if (DispatchAddress.GetBrokenRules().Count > 0)  
        {  
            AddToBrokenRulesList(brokenRules,  
            DispatchAddress.GetBrokenRules());  
        }  
        // ......  
        return brokenRules;  
    }  
} 

Order業(yè)務(wù)類(lèi)的一部分代碼，但是從代碼中可以看出，這個(gè)類(lèi)中包含了很豐富的業(yè)務(wù)邏輯。例如，在Process方法中，處理了下面的流程：

1．  調(diào)用CanProcess 方法來(lái)進(jìn)行下面的驗(yàn)證：

a.       Order的是否處于合適的可以被處理的狀態(tài)

b.       在Order中訂購(gòu)的物品是否有足夠的庫(kù)存

2． customer用戶(hù)給這個(gè)order付款。至于怎么付款，這個(gè)邏輯就包含在了card類(lèi)中。

3． 然后，對(duì)產(chǎn)品的庫(kù)存進(jìn)行更新。

可以看出，采用Domain Model方式很適合來(lái)來(lái)組織復(fù)雜的業(yè)務(wù)邏輯，而且代碼也很容易閱讀和理解(如果在加上重構(gòu))。

3.  總結(jié)

通過(guò)上面的一些分析和解釋?zhuān)恢来蠹沂欠瘳F(xiàn)在已經(jīng)清楚：之前提出的問(wèn)題如何解決。

一個(gè)建議就是：不要太形式化，根據(jù)項(xiàng)目的實(shí)際情況來(lái)。這句話可以使相當(dāng)于廢話，但是很多的情況確實(shí)是這樣的，DDD不是***的，Transaction Script和Active Record也有它們的優(yōu)勢(shì)，合適就好。 

原文標(biāo)題：架構(gòu)設(shè)計(jì)解惑

鏈接：http://www.cnblogs.com/yanyangtian/archive/2010/07/13/1776355.html

【編輯推薦】

1. UML用例建模的慨念和應(yīng)用
2. Eclipse UML插件及其安裝步驟簡(jiǎn)明介紹
3. 解析五大UML圖形的建立步驟
4. 專(zhuān)家指導(dǎo) 如何使Eclipse和UML工具EA進(jìn)行連接
5. 把Eclipse UML插件集成至Eclipse如何實(shí)現(xiàn)