我必须承认我一直在携带“存储库不应该返回IQueryable”横幅，因为它更难测试。我受到this和this等其他问题的答案的影响。
今天早上我一直在阅读ScuttGu关于ASP.NET vNext的博客，在那里他使用SelectMethod详细介绍了Model Binding，它似乎依赖于IQueryable进行分页和排序。
您认为这会迫使我们重新考虑IQueryable在存储库中扮演的角色吗？
答案 0 :(得分：9)
DDD Repository应该封装数据访问技术性：
定义：存储库是一种封装存储的机制， 检索和模拟对象集合的搜索行为。
它还负责处理域对象的中间和寿命结束。存储库接口属于Domain，应尽可能基于Ubiquitous Language。除了DDD书之外，这两篇文章几乎涵盖了设计存储库时需要了解的所有内容：
在我看来，在Repository接口上公开IQueryable并不是最佳选择。 IQueryable不是普适语言的一部分。这是一个技术性，它没有域意义。而不是封装数据检索Repository会暴露裸数据访问机制，这基本上会破坏首先拥有Repository的目的。
关于ASP.NET。这是一个UI框架。为什么允许UI框架影响域模型的设计？ Microsoft的例子经常鼓励将UI数据网格直接绑定到数据库表。或者，最近，控件绑定到所谓的域模型，而实际上是Anemic Model，或者只是带有gets / sets的哑数据容器。你提到的文章的引用（我强调一点）：
模型绑定是一种以代码为中心的数据绑定方法。它允许 你在你的代码隐藏文件中编写 CRUD 帮助方法 页面，然后轻松地将它们连接到其中的任何服务器控件 页。然后，服务器控件将负责调用方法 在页面生命周期的适当时间和数据绑定数据。
我对此的解释是抛弃模型和对象，只是将数据绑定到UI。在很多情况下，这可能是一种有效且合理的方法。但由于这个问题被标记为DDD，我会说在DDD中这称为Smart UI Anti-Pattern。