【转】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

```
[TestMethod]
```
```
public void FindCustomerTest()
```
```
{
```

    Customer customer = Customer.CreateCustomer("daxnet", "12345",

        new Name { FirstName = "Sunny", LastName = "Chen" },

        new Address(), new Address(), DateTime.Now.AddYears(-29));

    using (EntitiesContainer ec = new EntitiesContainer())

```
    {
```

        ec.Customers.AddObject(customer);

```
        ec.SaveChanges();
```
```
    }
```

    using (EntitiesContainer ec = new EntitiesContainer())

```
    {
```

        var query = from cust in ec.Customers

                    where cust.Name.FirstName.Equals("Sunny")

```
                    select cust;
```

        Assert.AreNotEqual(0, query.Count());

```
    }
```
```
}
```

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

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

总结

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

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

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

-----【以下为原文网友评论及回复信息】-----

Re:实体框架之领域驱动实践（八）

[ 2010-2-24 11:22:00 | By: 文野(游客) ]

你好，我同意衡量系统架构优劣度的重要指标，就是领域模型的纯净度这个观点。但我一直有一些疑惑，很多ORM框架，或象上面例子中，给领域对象添加一些Attribute，作为实体在持久化或其它方面的指导，这些Attribute，是不是使得领域模型变得不够纯净了？象上面的 [AggregateRoot（“Customers”）]，至少从感觉上觉得，它跟领域模型或者说业务领域一点关系都没有。如果要得到更纯净的领域模型，是不是可以加一层领域模型与数据持久模型的映射，这样会不会好点？

以下为blog主人的回复：
如果你是使用 NHibernate，那么，你就需要在外部维护一个xml文件，用来表述实体与外部数据表的映射关系。这个xml文件打断了领域模型与 NHibernate的耦合，那么在使用的时候，你就可以根据本文介绍的办法，使用NHibernate的Session实现你自己的仓储，同样，使用依赖注入将其注射到领域模型中。
的确有不少具有ORM类似功能的框架，在领域模型中使用了Attribute以确定对象的持久化方式，经典的代表作是Castle ActiveRecord以及微软的LINQ to SQL。在这些案例中，所使用的Attribute直接定义了数据持久化方面的细节，也如你所说，打破了领域模型的纯净度。
在本文的案例中，AggregateRootAttribute与那些框架中所使用的Attribute不同，AggregateRoot是领域模型中的概念，而与具体的技术实现无关。换句话说，AggregateRootAttribute并没有去“指使”整个领域模型去做某些与领域无关的事情。如果你的仓储实现不需要用到这个Attribute（比如NHibernate的实现），你完全可以对其置之不理。
AggregateRootAttribute和IAggregateRoot接口一起，用以表述“被修饰的类指代的是一种聚合根”的概念，它跟具体的技术架构实现并无太大关系。

Re:实体框架之领域驱动实践（八）

[ 2010-2-26 16:03:00 | By: haojie77 ]

"EdmRepository将实体框架抽象到ObjectContext这一层，这也使我们没法通过LINQ to Entities来查询模型中的对象." 从现在的实现方式看, 拥有ObjectContext的CustomerRepository是否被一直缓存起来了? 这是否意味着数据库的链接始终保持着? 目前的EdmRepository只能进行聚合根的CRUD操作, 如果要获得聚合中的其他实体(势必要使用linq to entity的操作, 若不对请加以指正), 要在哪里实现呢? 是否在EdmRepository中追加定义一些specification的查询? (在<<NET.Domain.Driven.Design.with.C#>>中聚合中的其他实体也是从该聚合根的 Repository来获得.) 非常期待您之后的讲座!

以下为blog主人的回复：
首先，本文所讨论的只是仓储的一种松耦合实现方式，有关ObjectContext生命周期的问题，我会在下一讲中阐述。因为仓储的操作是事务性的，在下一讲我会引入 “事务上下文”（Transaction Context）的概念，你就会明白事务上下文是如何管理ObjectContext的了；其次，要获得聚合内部的实体，只能通过聚合根来实现：1、通过 Repository获得聚合根实体；2、使用聚合根实体的属性、方法直接获得聚合内的实体。比如：
IRepository<Customer> custRep = container.GetService<IRepository<Customer>>(); Customer sunny = custRep.GetBySpecification(new NameSpecification("Sunny Chen")); sunny.Address = xxxx;
于是，这个Address对象就是通过sunny这个聚合根实体来获得的。我想想这个跟你所说的<<.NET DDD>>一书中的描述是一样的。

Re:实体框架之领域驱动实践（八）

[ 2010-2-28 0:14:00 | By: ruson(游客) ]

按您文中所述，领域模型中用到了仓储，这里项目如果分开的话就会有相互引用，因为仓库实现中会用到领域Domain。虽然用依赖注入可以解决。但觉得这本身已经不太合理了。
领域模型应该是纯净的，只关注领域业务，而不需要知道有仓储的存在。仓储应该由service去调用，service调用仓储来做领域的持久化操作。

以下为blog主人的回复：
对于领域模型是否能够直接使用仓储，国外很多领域驱动的社区对此有很大的争议。有的人认为，领域模型不应该直接使用仓储，有的人认为，这样做并没有什么不妥，事实上也有类似的大型成功案例，在领域模型中直接使用仓储实现实体持久化。所以这并没有一个绝对的标准。DDD是一种实践指导，而不是一种绝对的理论。所以，在目前需求的界定下，只要合理，就是好的架构。
此外，关于Service，DDD将Service分为三种：Application Service，Domain Service以及Infrastructure Service。Evans在他的DDD一书中有个很好的例子，详细解释了三者的区别。你所说的应该是Domain Service，既然是Domain Service，那么他也是领域层的一部分，因此，是由Service来调用仓储，还是由实体本身来调用，已经变得不重要了。
Service用以处理依靠单个实体无法完成的领域逻辑，它也需要关注领域模型中的方方面面。如果实体不允许使用仓储，那么仅仅由Service去使用也会变得不合理。

Re:实体框架之领域驱动实践（八）

[ 2010-2-28 0:21:00 | By: ruson(游客) ]

没有最好的架构，只有最合理的架构。当系统不复杂且大部分都是对单一表的CURD操作时，领域驱动就变得像贫血模型，感觉是个鸡肋。

以下为blog主人的回复：
对于软件架构，我一直都持有保留意见，我主张不要过分的去强调某些技术或者某些概念，以使其能够成为一种所谓合理的架构。软件开发的整个过程都是需求驱动的，需求决定架构这是毋庸置疑的。此外，本系列文章所讨论的都是基于领域驱动思想下的软件架构实践，当然不会适用于所有的软件系统。如果你的软件简单到只需要输出一行Hello World，你甚至连面向对象都不需要了。

Re:实体框架之领域驱动实践（八）

[ 2010-3-1 16:10:00 | By: haojie77 ]

您说的这个Address只是一个Customer的属性. 我想知道的是如何得到某个特殊的在Customer聚合中的实体.
根据"2、使用聚合根实体的属性、方法直接获得聚合内的实体。" 那么如果是要查找某一个Customer的Order, 您的意思是否是可以直接在Customer的GetOrder(spec)内调用linq to entity?(这样做是否把技术相关的东西引入了Domain中?) 还是GetOrder内调用领域服务CustomerService.GetOrder(spec), 在其内再调用CustomerRepository.GetOrder(spec)? (因为之前有看到您也说不推荐让Entity直接使用Repository, 应该让Entity通过DomainService间接地去调用Repository.)

以下为 blog主人的回复：
你首先要知道，Address虽然是一个属性，但是从领域驱动上看，它是一个值对象。聚合包含的不仅仅全都是实体，还包含着值对象。这里我的例子就是通过聚合根访问聚合内部对象的方法。
针对你的问题，你完全可以直接在Customer上创建所需的方法来达到你的目的，没有必要引入Service，也不需要牵涉到Respository，因为聚合的另一层意义就是界定持久化的范围。换句话说，聚合中的所有对象都是“同时有，同时无”的。
比如，你可以创建这样的方法来达到你的需求：

class Customer
{
List<SalesOrder> GetUndeliveredOrders(SalesOrderSpecification spec);
}