EntityFramework之领域驱动设计实践（八）（转）

http://www.cnblogs.com/daxnet/archive/2010/07/07/1772780.html
仓储的实现：基本篇

我们先从技术角度考虑仓储的问题。实体框架（EntityFramework）中，操作数据库是非常简单的：在ObjectContext中使用 LINQ to Entities即可完成操作。开发人员也不需要为事务管理而操心，一切都由EF包办。与原本的ADO.NET以及LINQ to SQL相比，EF更为简单，LINQ to Entities的引入使得软件开发变得更为“领域化”。
下面的代码测试了持久化一个 Customer实体，并从持久化机制中查询这个Customer实体的正确性。从代码中可以看到，我们用了一种很自然的表达方式，表述了“我希望查询一个名字为Sunny的客户”这样一种业务逻辑。

隐藏行号 复制代码 ？ FindCustomerTest 
  1. [TestMethod] 
  2. public void FindCustomerTest() 
  3. { 
  4.     Customer customer = Customer.CreateCustomer("daxnet", "12345", 
  5.         new Name { FirstName = "Sunny", LastName = "Chen" }, 
  6.         new Address(), new Address(), DateTime.Now.AddYears(-29)); 
  7.     using (EntitiesContainer ec = new EntitiesContainer()) 
  8.     { 
  9.         ec.Customers.AddObject(customer); 
  10.         ec.SaveChanges(); 
  11.     } 
  12.     using (EntitiesContainer ec = new EntitiesContainer()) 
  13.     { 
  14.         var query = from cust in ec.Customers 
  15.                     where cust.Name.FirstName.Equals("Sunny") 
  16.                     select cust; 
  17.         Assert.AreNotEqual(0, query.Count()); 
  18.     } 
  19. }

如果你需要实现的系统并不复杂，那么按上面的方式添加、查询实体也不会有太大问题，你可以在 ObjectContext中随心所欲地使用LINQ to Entities来方便地得到你需要的东西，更让人兴奋的是，.NET 4.0允许支持并行计算的PLINQ，如果你的计算机具有多核处理器，你将非常方便地获得效率上的提升。然而，当你的架构需要考虑下面几个方面时，单纯的 LINQ to Entities方式就无法满足需求了：

  1. 领域模型与技术架构分离。这是DDD的一贯宗旨，也就是说，领域模型中是不能混入任何技术架构实现的，业务和技术必须严格分离。考察以上实现，领 域模型紧密依赖于实体框架，而目前实体框架并非是完全领域驱动的，它更偏向于一种技术架构。比如上面的Customer实体，在实体框架驱动的设计中，它 已经被EF“牵着鼻子走”了
  2. 规约（Specification）模式的引入。以上实现中，虽然LINQ使得业务逻辑的表述方式更为“领域化”，可以看成是一种 Domain Specific Language（Microsoft Dynamics AX早已引入了类似的语言集成的语法），但这种做法会使得模型对领域概念的描述变得难以更改。比如：可以用“from employee in employees where employee.Age >= 60 && employee.Gender.Equals(Gender.Male) select employee”来表述“找出所有男性退休职工”的概念，但这种逻辑是写死在领域模型中的，倘若某天男性退休的年龄从60岁调至55岁，那么上面的查询 就不正确了，此时不得不对领域模型作修改。更可怕的是，LINQ to Entities仍然没有避免“SQL everywhere”的难处，领域模型中将到处充斥这这种LINQ查询，弊端也不多说了。解决方法就是引入规约模式
  3. 仓储实现的可扩展性。比如如果经过系统分析，发现今后可能需要用到其它的持久化解决方案，那么你就不能直接使用实体框架

于是，也就回到了上篇博客中我描述的问题：仓储不是Data Object，也不仅仅是进行数据库CRUD操作的Data Manager，它承担了解耦领域模型和技术架构的重要职责。为了完美地解决上面提到的问题，我们仍然采用领域驱动设计中仓储的设计模式，而将实体框架作 为仓储的具体实现部分。在详细介绍仓储的设计与实现之前，让我们回顾一下上文最后部分我提到的那个仓储的接口：

隐藏行号 复制代码 ？ IRepository 
  1. public interface IRepository<TEntity> 
  2.     where TEntity : EntityObject, IAggregateRoot 
  3.  { 
  4.     void Add(TEntity entity); 
  5.     TEntity GetByKey(int id); 
  6.     IEnumerable<TEntity> FindBySpecification(Func<TEntity, bool> spec); 
  7.     void Remove(TEntity entity); 
  8.     void Update(TEntity entity); 
  9. }

在本文的案例中，仓储是这样实现的：

  1. 将上述仓储接口定义在实体、值对象和服务所在的领域层。有朋友问过我，既然仓储需要与外 部存储机制打交道，那么它必定需要知道技术架构方面的细节，而将其定义在领域层，就会使得领域层依赖于具体的技术实现方式，这样就会使领域层变得“不纯 净” 了。其实不然！请注意，我们这里仅仅只是将仓储的接口定义在了领域层，而不是仓储的具体实现（Concrete Repository）。更通俗地说，接口作为系统架构的基础元素，决定了整个系统的架构模式，而基于接口的具体实现只不过是一种可替换的组件，它不能成为系统架构中的一部分。由于领域层需要用到仓储，我便将仓储的接口定义在了领域层。当然，从.NET的实现技术考虑，你可以新建一个Class Library，并将上述接口定义在这个Class Library中，然后在领域层和仓储的具体实现中分别引用这个Class Library
  2. 新建一个Class Library（在本文的案例中，命名为EasyCommerce.Infrastructure.Repositories），添加对领域层 assembly的引用，并实现上述接口。由于我们采用实体框架作为仓储的具体实现，因此，将这个仓储命名为EdmRepository（Entity Data Model Repository）。EdmRepository有着类似如下的实现：
    隐藏行号 复制代码 ？ EdmRepository实现
    1. internal class EdmRepository<TEntity> : IRepository<TEntity> 
    2.     where TEntity : EntityObject, IAggregateRoot 
    3.  { 
    4.     #region Private Fields 
    5.         private readonly ObjectContext objContext; 
    6.         private readonly string entitySetName; 
    7.         #endregion 
    8.   
    9.     #region Constructors 
    10.     /// <summary> 
    11.     ///  
    12.     /// </summary> 
    13.     /// <param name="objContext"></param> 
    14.  public EdmRepository(ObjectContext objContext) 
    15.     { 
    16.         this.objContext = objContext; 

    18.         if (!typeof(TEntity).IsDefined(typeof(AggregateRootAttribute), true)) 
    19.             throw new Exception(); 

    21.         AggregateRootAttribute aggregateRootAttribute = (AggregateRootAttribute)typeof(TEntity) 
    22.             .GetCustomAttributes(typeof(AggregateRootAttribute), true)[0]; 

    24.         this.entitySetName = aggregateRootAttribute.EntitySetName; 
    25.     } 
    26.     #endregion 
    27.   
    28.     #region IRepository<TEntity> Members 

    30.         public void Add(TEntity entity) 
    31.         { 
    32.             this.objContext.AddObject(EntitySetName, entity); 
    33.         } 

    35.         public TEntity GetByKey(int id) 
    36.         { 
    37.             string eSql = string.Format("SELECT VALUE ent FROM {0} AS ent WHERE ent.Id=@id", EntitySetName); 
    38.             var objectQuery = objContext.CreateQuery<TEntity>(eSql, 
    39.                 new ObjectParameter("id", id)); 
    40.             if (objectQuery.Count() > 0) 
    41.                 return objectQuery.First(); 
    42.             throw new Exception("Not found"); 

    44.         } 

    46.         public void Remove(TEntity entity) 
    47.         { 
    48.             this.objContext.DeleteObject(entity); 
    49.         } 

    51.         public void Update(TEntity entity) 
    52.         { 
    53.             // TODO 
    54.  } 

    56.         public IEnumerable<TEntity> FindBySpecification(Func<TEntity, bool> spec) 
    57.         { 
    58.             throw new NotImplementedException(); 
    59.         } 

    61.         #endregion 
    62.   
    63.     #region Protected Properties 
    64.         protected string EntitySetName 
    65.         { 
    66.             get { return this.entitySetName; } 
    67.         } 

    69.         protected ObjectContext ObjContext 
    70.         { 
    71.             get { return this.objContext; } 
    72.         } 
    73.         #endregion 
    74. }

    从上面的代码可以看到，EdmRepository将实体框架抽象到 ObjectContext这一层，这也使我们没法通过LINQ to Entities来查询模型中的对象。幸运的是，ObjectContext为我们提供了一系列函数，用以实现实体的CRUD。为了使用这些函数，我们需 要知道与实体相关的EntitySetName，为此，我定义了一个AggregateRootAttribute，并将其应用在聚合根上，以便在对实体 进行操作的时候，能够正确地获得EntitySetName。类似的代码如下：

    隐藏行号 复制代码 ？ Customer Partial Class 
    1. [AggregateRoot("Customers")] 
    2. partial class Customer : IAggregateRoot 
    3. { 
    4.      
    5. }

    回头来看EdmRepository的构造函数，在构造函数中，我们使用.NET的反射机制获得了定义在聚合根类型上的EntitySetName

     

  3. 使用IoC/DI（控制反转/依赖注入）框架，将仓储的实现（EdmRepository）注射到领域模型中。至此，领域模型一直保持着对仓储接口的引用，而对仓储的具体实现方式一无所知。由于IoC/DI的引入，我们得到了一个纯净的领域模型。在这里我也想提出一个衡量系统架构优劣度的重要指标，就是领域模型的纯净度。常见的 IoC/DI框架有Spring.NET和Castle Windsor MicroKernel。在本文的案例中，我采用了Castle Windsor。以下是针对Castle Windsor的配置文件片段：
    隐藏行号 复制代码 ？ Customer Partial Class 
    1. <castle> 
    2.   <components> 
    3.     <!-- Object Context for Entity Data Model --> 
    4.     <component id="ObjectContext"  
    5.                service="System.Data.Objects.ObjectContext, System.Data.Entity, Version=4.0.0.0, Culture=neutral, 
    6.  type="EasyCommerce.Domain.Model.EntitiesContainer, EasyCommerce.Domain"/> 
    7.  
    8.     <component id="CustomerRepository" 
    9.                service="EasyCommerce.Domain.IRepository`1[[EasyCommerce.Domain.Model.Customer, EasyCommerce.Doma 
    10.  type="EasyCommerce.Infrastructure.Repositories.EdmRepositories.EdmRepository`1[[EasyCommerce.Doma 
    11.       <objContext>${ObjectContext}</objContext> 
    12.     </component> 
    13.   
    14.   </components> 
    15. </castle> 
    16.

    通过这个配置片段我们还可以看到，在框架创建针对“客户”实体的仓储实例时，我们案例中的领域模型容器（EntitiesContainer）也以构造器注入的方式，被注射到了EdmRepository的构造函数中。接下来我们做一个单体测试：

    161914254244
    考察上面的代码，仓储的使用者（Client，可以是领域模型中的任何对象）对仓储的具体实现一无所知

总结 

总之，仓储的实现可以用下图表述：

191014782220

回头来看本文刚开始的三个问题：依赖注入可以解决问题1和3，而仓储接口的引入，也使得规约模式的应用成为可能。.NET中有一个泛型委托，称为 Func<T, bool>，它可以作为LINQ的where子句参数，实现类似规约的功能。有关规约模式，我将在其它的文章中讨论。

从本文还可以了解到，依赖注入是维持领域模型纯净度的一大利器；另一大利器是领域事件，我将在后续的文章中详述。对于本文开始的第三个问题，也就是仓储实现的可扩展性，将在下篇文章中进行讨论，包括的内容有：事务处理和可扩展的仓储框架的实现。

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/quietwalk/p/2229881.html