asp.net - IQueryable & Repositories - 拿 2 个？

Question

我不得不承认我一直带着“存储库不应返回 IQueryable”的横幅，因为它更难测试。我受到其他问题的回答的影响，例如 this和 this .

今天早上我一直在阅读 ScuttGu 关于 ASP.NET vNext 的博客。他在其中详细介绍了使用似乎依赖 IQueryable 进行分页和排序的 SelectMethod 的模型绑定(bind)。

你认为这会迫使我们重新考虑 IQueryable 在存储库中扮演的角色吗？

Answer 1

DDD Repository应该封装数据访问技术:

Definition: A Repository is a mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects.

它还负责处理域对象的中间和结束生命周期。 Repository 接口(interface)属于Domain，应该基于 Ubiquitous Language越多越好。除了 DDD 书之外，这两篇文章几乎涵盖了您在设计存储库时需要了解的所有内容:

How To Write A Repository

The Generic Repository

在我看来，在 Repository 接口(interface)上公开 IQueryable 并不是最佳选择。 IQueryable 不是通用语言的一部分。这是一种技术性，它没有领域意义。而不是封装数据检索 Repository 将暴露裸数据访问机制，这基本上违背了首先拥有 Repository 的目的。

关于 ASP.NET。这是一个 UI 框架。为什么你会允许 UI 框架影响你的领域模型的设计？ Microsoft 示例经常鼓励直接绑定(bind)到数据库表的 UI 数据网格之类的东西。或者，最近，控件绑定(bind)到所谓的域模型，而实际上它是 Anemic Model ，或者只是带有gets/sets的哑数据容器。您提到的文章中的引述(我强调了一点):

Model binding is a code-focused approach to data-binding. It allows you to write CRUD helper methods within the code-behind file of your page, and then easily wire them up to any server-controls within the page. The server-controls will then take care of calling the methods at the appropriate time in the page-lifecycle and data-bind the data.

我对此的解释是抛弃模型和对象，只将数据绑定(bind)到 UI。在很多情况下，这可能是一种有效且合理的方法。但是由于这个问题被标记为 DDD 我会说在 DDD 这被称为 Smart UI Anti-Pattern .