Fork me on GitHub
架构设计解惑[转]

架构设计解惑

 

  前言:之前的文章,很多朋友发来了反馈,从反馈中也看出了一些问题,一个最明显的问题就是:当我提到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的方法来套.也就是说,不要为了DDDDDD.就像当初我们学习设计模式一样,没有必要在写代码的过程中为了设计模式而设计模式.

 

 

 

 

 

  2.       设计方法

 

 

 

到底是采用DDD还是那种朴实的三层,主要取决与业务层的设计和系统的复杂度.

 

 

 

  如果系统确实很复杂,业务逻辑相当的复杂,那么建议采用DDD,因为DDD的引入就是用解决复杂性的.因为采用DDD的方法来设计业务逻辑层,那么业务逻辑层就只是关注业务逻辑的处理,至于怎么存储和获取数据,丝毫不关心,所以基于这个原因,DDD中就引入了Repository的概念,Repository就是来辅助业务逻辑层处理数据的.

 

 

 

  虽然我一直在提朴实的三层”,其实DDD和它之间没有什么很明显的划分了,这里我之所以特意的把他们划分出来,主要就是因为我们在项目开发中一般是三层(或者N),这里提出主要是为便于后面讲述一些问题.

 

 

 

下面就开始讲述一些业务逻辑层设计方法,相信大家看完之后,很多的疑惑就迎刃而解了.

 

业务层的设计方法有三种:Transaction Script, Active RecordDomain Model.

 

 

 

看过Flower<<企业架构模式>>一书的朋友应该对上面的三个词语很熟悉,在书中,这些概念讲的确实很精炼,可能因为精炼,所以理解起来就不是很容易.

 

在本篇文章中,就涉及到了这些知识,只有把这些点讲清楚了,之前的问题就能解决.

 

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

 

 

 

首先来看看Transaction Script(之所以没有翻译为中文,因为翻译后的中文意思很容易让人产生误导)

 

其实Transaction Script就是过程化的设计方式,最直观表现就是一个个的方法,每个方法做一个业务的流程。我们来看下面一个例子。例子的背景就是在电子商务网站中订单的处理流程。

 

 

 

 

 

代码
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
        }
    }

 

 

 

 

 在上面的代码中,所有和订单处理有关的逻辑都写在OrderManager类中。类中的每一个方法就对应业务逻辑中的一个流程或者说对应一个use case,例如:CancelOrder就是取消订单。

 

 

 

通过Transaction Script的方式来组织业务逻辑,一个很好的好处就是直观,很容易理解代码在做什么。如果有新的流程来了,再加一个方法就行了。

 

 

 

同时,这种组织方式的弊端就在于,当系统中的业务变得多而且复杂的时候,那么这样的方法就开始变多,最后的结果就是一个类中有成百上千个方法。而且这些方法中,除了一些基本的验证可以提取为方法重用,其他的流程控制代码在很多的地方要重写,特别是当有两个流程差不多的时候,代码不可避免的重新写。于是,这样的类开始变得庞大而难以管理。

 

 

 

Active Record

 

  

 

这种组织方式已经是我们最熟悉的了。

 

在很多的项目中,我们的业务实体类基本和数据库中表是一一对应的,例如一个Order业务类就是代表了数据库中的Order表。而且在平时项目中,朴实的三层(N)”,一般都是基于这种方式在组织逻辑。

 

 

 

 

 

 

这种方式的最大的区别就是每个业务类自己负责自己的数据存取,也就是说在业务类中包含了业务逻辑的处理和数据的存取。

 

例如:

 

 

 

 

代码
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类包含了业务逻辑处理的代码,如Cancel, Process。通过这些方法也调用了数据访问代码来保存数据。

 

 

 

如果在开发的项目中,业务类和数据表是一一对应的关系,例如在开发博客或者论坛,Active Record方式就很合适。

 

 

 

相信很多的项目都是基于这个方式在开发和组织逻辑层,这个方式最大的弊端就是:数据库表只要改动,那么业务逻辑层动,而且这种变动会一直波及到了UI那端。

 

 

 

Domain Model

 

通过用这种方式来组织业务层的时候,业务层就只是关注把现实中的概念转换为相应的业务逻辑模型,不关注其他的方面。例如,在电子商务网站开发中,一些概念就被建模表示为一个个的业务模型(也就是业务类)Order, Shopping Cart, Customer等。而且和Active Record最大的区别就是:Domain Model中的业务类不是和表一一对应的,下图就是一个很好的例子:

 

 

 

 

而且最主要的特点就是:每个业务类包含了很多的业务验证,状态跟踪等。职责很单一,便于维护和理解。

 

示例代码如下:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

代码
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业务类的一部分代码,但是从代码中可以看出,这个类中包含了很丰富的业务逻辑。例如,在Process方法中,处理了下面的流程:

 

1.  调用CanProcess 方法来进行下面的验证:

 

a.       Order的是否处于合适的可以被处理的状态

 

b.       Order中订购的物品是否有足够的库存

 

2. customer用户给这个order付款。至于怎么付款,这个逻辑就包含在了card类中。

 

3. 然后,对产品的库存进行更新。

 

可以看出,采用Domain Model方式很适合来来组织复杂的业务逻辑,而且代码也很容易阅读和理解(如果在加上重构)

 

 

 

 

 

  3.       总结

 

通过上面的一些分析和解释,不知道大家是否现在已经清楚:之前提出的问题如何解决。

 

一个建议就是:不要太形式化,根据项目的实际情况来。这句话可以使相当于废话,但是很多的情况确实是这样的,DDD不是万能的,Transaction ScriptActive Record也有它们的优势,合适就好。 

 

   谢谢各位!

 

 

 

  版权为小洋和博客园所有,欢迎转载,转载请标明出处给作者。

 

   http://www.cnblogs.com/yanyangtian

 

小洋,燕洋天

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

posted on 2010-07-14 09:20  HackerVirus  阅读(230)  评论(0编辑  收藏  举报