在上一篇文章中，我们讨论了两种组织业务逻辑的模式：Transaction Script和Active Record。在本篇中开始讲述Domain Model和Anemic Model。

　　Domain Model

　　在开发过程中，我们常常用Domain Model来对目标的业务领域建模。通过Domain Model建模的业务类代表了目标领域中的一些概念。而且，我们会看到通过Domain Model建模的一些对象模拟了业务活动中的数据，有的对象还反映了一些业务规则。

　　我们就来看看电子商务系统的开发，在开发中我们建立了一些概念的模型来反映电子商务领域中的一些概念：购物车，订单，订单项等。这些模型有自己的数据，行为。例如一个订单模型，它不仅仅包含一些属性（流水号，创建日期，状态）来包含自己的数据，同时它也包含了一些业务逻辑：下订单的用户时候合法，下订单用户的余额是否充足等。

　　一般来说，我们对领域了解的越深，我们在软件中建立的模式越接近现实中的概念，最后实现的软件就越符合客户的需求。同时在建模的过程中，也要考虑模型的可实现行，可能我们对领域进行了很好的建模，和符合目标领域的一些概念，但是在软件实现起来非常的困难，那么就得权衡一下：找出一个比较好的模式，同时也便于实现。

　　在以前的文章中其实也提到过一些有关Domain Model的一些东西，其实Domain Model和Active Record的一个区别在于：Domain Model不知道自己的数据时如何持久化的，即PI（Persistence Ignorance）.也就是说，通过Domain Model建立的业务类，都是POCO（Plain Old Common Runtime Object）。

　　下面我们就用一个银行转账的例子来讲述一下Domain Model的应用。创建一个新的解决方案，命名为ASPPatterns.Chap4.DomainModel，并且添加如下的项目：

　　ASPPatterns.Chap4.DomainModel.Model

　　ASPPatterns.Chap4.DomainModel.AppService

　　ASPPatterns.Chap4.DomainModel.Repository

　　ASPPatterns.Chap4.DomainModel.UI.Web

　　编译整个，Solution，然后添加引用：

　　为Repository项目添加Model 的引用。

　　为AppService项目添加Model和Repository的引用。

　　为Web项目添加AppService的引用。

　　下面就来看看每个项目代表的含义：

　　ASPPatterns.Chap4.DomainModel.Model:在这个project中包含了系统中所有的业务逻辑和业务对象，以及业务对象之间的关系。这个project也定义了持久化业务对象的接口，并且用Repository 模式来实现的（Repository 模式我们后面会谈到的）。大家可以看到：这个Model的project没有引用其他的project，也就是说这个Model的project完全关注于业务。

　　ASPPatterns.Chap4.DomainModel.Repository：这个Repository的project实现了包含在Model project中定义的持久化接口。而且Repository还引用了Model project，就是用来持久化Model的数据的。

　　ASPPatterns.Chap4.DomainModel.AppService：AppService project就扮演者一个应用层的角色，或者理解为门户入口，因为提供了一些比较粗颗粒度的API，并且它和Presenter层之间通过消息的机制来进行通信。（消息模式我们以后也会讲述）而且在AppService中，我们还会定义一些view model，这些view model的就符合也最后要显示的数据结构，view model的数据可能是很多业务对象数据的组合，或者仅仅就是这业务对象数据的格式转换等等。

　　ASPPatterns.Chap4.DomainModel.UI.Web:这个Web.UI project主要是负责最后的显示逻辑和一些用户体验的实现。这个project就调用AppService提供的API，获取符合界面显示的强类型的view model，然后显示数据。

　　系统的这整个结构如下：

　　下面就开始创建保存数据的数据库，和以前一样，为了演示的作用，我们在Web project中添加一个名为BankAccount.mdf的数据库，并且建立如下的表：

　　BankAccount 表

　　Transaction 表

　　下一步就开始为领域建模，因为这里的例子比较简单和常见，建模的过程就省了，最后就得到了表示领域概念的两个领域对象（或者说业务对象）：

public class Transaction
    {
        public Transaction(decimal deposit, decimal withdrawal, string reference, DateTime date)
        {            
            this.Deposit = deposit;
            this.Withdrawal = withdrawal;
            this.Reference = reference;
            this.Date = date;
        }
              
        public decimal Deposit
        { get; internal set; }

        public decimal Withdrawal
        { get; internal set; }

        public string Reference
        { get; internal set; }

        public DateTime Date
        { get; internal set; }
    }        

        

        
        
      
        
NET技术：走向ASP.NET架构设计——第四章—业务层分层架构（中篇），转载需保留来源！
        
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。