前面已经介绍过Entity Framework的工作单元和映射层超类型的封装，从本文开始，将逐步介绍仓储以及对查询的扩展支持。
仓储表示聚合的集合。
仓储所表现出来的集合外观，仅仅是一种模拟，除了测试以外，没有理由使用内存中真正的集合来创建仓储。
不应该为所有实体建立仓储，只有聚合才拥有仓储。
仓储用来重建已持久化的聚合，而工厂用于新建聚合。
直接使用Entity Framework的DbContext不是很好吗，为什么还要在DbContext的上方封装一层仓储呢，这是否多此一举？
很多使用EF的程序员确实是直接使用DbContext，并且他们发现开发起来十分简单，因为DbContext的接口设计得非常优雅，从接口上看，DbContext就好像所有实体集合的仓库。
另一方面，很多使用了仓储的朋友，都是依葫芦画瓢，虽然创建了仓储，但并没有体会到多大好处。
下面简要介绍使用仓储将为你带来的优点。
仓储模拟了某种聚合的集合，而DbContext包含了N种类型的集合。
与仓储相近的一个数据访问模式是数据访问对象（DAO）模式，很多人认为仓储不过是数据访问对象换了一个名词而已，从技术上说的确如此，仓储的强大之处在于概念上更简单。仓储在概念上代表内存中的集合操作，而数据访问对象代表数据库操作，很明显，集合比数据库在概念上更简单。
如果直接使用DbContext，由于特定查询逻辑没有一个固定位置，可能分散到任何地方，这很容易造成冗余。
仓储是封装特定查询逻辑的好地方，对于特定的查询逻辑，放到与聚合相应的仓储中即可。
直接使用DbContext，所有调用代码与EF实现高度耦合。
另一方面，由于DbContext能够获取任意实体，这些实体可能位于聚合内部，这样会破坏聚合的封装性，同时在任意位置可以获取任意对象，由于缺乏约束力而导致更高的耦合。
直接使用DbContext只能进行集成测试，必须连接到真实数据库。而领域层只持有仓储接口，所以测试时很容易替换成模拟实现，从而避开数据库。
一般来讲，ICustomerRepository比直接使用泛型的IRepository<Customer>要好。
为了定义通用操作，我们会创建一些泛型基类来实现基础操作。
有些人发现很多具体仓储只是直接继承泛型仓储，比如ICustomerRepository和CustomerRepository从泛型的IRepository<Customer>和Repository<Customer>派生，但CustomerRepository本身并没有其它什么代码。于是很多人学会偷懒，直接使用泛型基类进行操作。
ICustomerRepository优于IRepository<Customer>的原因如下。
1. 概念上更清晰。
ICustomerRepository从概念上良好表达了该仓储用于操作客户，而泛型仓储可以操作任何聚合。
2. 为特定查询逻辑提供唯一封装和访问点。
ICustomerRepository可以将客户相关的各种复杂查询封装起来，而IRepository<Customer>很难对客户查询进行封装，一个办法是使用扩展方法来完成封装，不过比起CustomerRepository要麻烦得多，而且实现代码也更难管理。
3. 降低耦合。
泛型IRepository<>可以在任意位置获取任意聚合，这比起DbContext要强一些，不会破坏聚合的封装性，但缺乏约束力仍然会导致更高耦合。
ICustomerRepository通过明确的声明，只能获取需要的聚合，从而控制了对象的访问。
仓储可以返回对应的聚合，也可以返回聚合相关的统计信息，甚至可以返回聚合的一个子集。
有人在仓储查询中使用匿名对象，使用匿名对象的原因很简单，即为了进行投影操作，这样可以限制Sql查询返回的列，对于Sql性能调优来讲，这可能非常重要，比如使用Sql Server的覆盖索引。
但是使用匿名对象进行查询有很多问题，一个问题是无法直接作为结果返回。有人为了省力，直接使用聚合或其部分子对象作为返回类型，其结果是对象中的一部分属性被赋值，另一部分属性为null。这可能导致许多神秘的Bug，另外导致你或其它人对仓储查询信心不足，因为这些查询并不安全，你每当需要调用一个查询，首先得仔细检查代码，看看哪些值是空的，以免踩到地雷。
如果要返回聚合的一个子集，需要单独定义一些对象，以作为返回类型。工作量虽然比较大，但更加安全和清晰。
如果需要获取的内容由多个聚合组成，这个查询操作应该放入哪个仓储中？这种情况放到哪个仓储其实都不合适，更好的办法是使用一个查询服务，就好像跨越多个聚合的业务操作需要领域服务一样。
1. 仓储的定义
仓储表示聚合的集合。
2. 仓储的优点
3. 仓储的要点
由于仓储是对数据操作的封装，包括仓储基础，分页，查询扩展，查询对象，查询条件（规约模式），查询条件应用（日期范围与数值范围查询）等内容，所以需要多篇文章进行介绍。
.Net应用程序框架交流QQ群: 386092459，欢迎有兴趣的朋友加入讨论。
谢谢大家的持续关注，我的博客地址：http://www.cnblogs.com/xiadao521/
相关文章
