我不得不承认我一直打着“存储库不应返回 IQueryable”的横幅，因为它更难测试。我受到this 和this 等其他问题的回答的影响。
今天早上，我一直在阅读 ScuttGu 的关于 ASP.NET vNext 的博客，其中他详细介绍了使用 SelectMethod 进行模型绑定，该 SelectMethod 似乎依赖于 IQueryable 进行分页和排序。
您认为这会迫使我们重新考虑 IQueryable 在存储库中所扮演的角色吗？
【问题讨论】：
标签： asp.net domain-driven-design repository iqueryable
DDD Repository 应该封装数据访问技术：
定义：Repository 是一种封装存储的机制， 模拟对象集合的检索和搜索行为。
它还负责处理域对象的中间和结束生命周期。 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。
【讨论】：