asp.net架构设计解惑

欢迎您访问我爱IT技术网，今天小编为你分享的编程技术是：【asp.net架构设计解惑】，下面是详细的分享！

asp.net架构设计解惑

前言：之前的文章，很多朋友发来了反馈，从反馈中也看出了一些问题，一个最明显的问题就是：当我提到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就是过程化的设计方式，最直观表现就是一个个的方法，每个方法做一个业务的流程。我们来看下面一个例子。例子的背景就是在电子商务网站中订单的处理流程。

代码

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;
    }
}

以上所分享的是关于asp.net架构设计解惑，下面是编辑为你推荐的有价值的用户互动：

　　相关问题：有没有高人为我详细描述下 asp.net中 框架 架构 设...

　　答：首先说框架 框架是比较复杂的 他其中可以包含很多类库 比如数据库操作方面的 网站通用库 也可以包含多种设计模式 MVC ，iOC注入，工厂模式 等等 其实只要我们使用.Net写程序 就已经使用了框架 。那是微软的.NetFrame框架 。也有很多牛人 或团队... >>详细

　　相关问题：ASP.NET分哪些架构，及开发模式？

　　答：分B/S和C/S架构。 开发模式有很多，比较常用的：三层架构，MVC模式，工厂模式 >>详细

　　相关问题：asp.net如何实现三层架构,

　　答：三层 首先你得有一个基本的面向对象的概念 DAL层你需要在VS建一个类库任意名字 里面存入你对应数据处理的类（增删改查） BLL层这里业务逻辑层你刚刚初学不用理会建立一个BLL类库里面就放入调用DAL层的方法 UI层就是你的ASPX和ASPX.cs 以及一般处... >>详细