IQueryable&存储库 - 需要 2 个？
我必须承认我一直打着“存储库不应返回 IQueryable”的旗帜，因为它更难测试。我受到其他问题的答案的影响，例如 this 和 这个。
今天早上我一直在阅读 ScuttGu 的博客，内容涉及 ASP.NET vNext，其中他详细介绍了使用似乎依赖于 IQueryable 的 SelectMethod 的模型绑定用于分页和排序。
您认为这会迫使我们重新考虑 IQueryable 在存储库中扮演的角色吗？
I have to admit I have been carrying the "Repository should not return IQueryable" banner because it is harder to test. I have been influenced by the answers to other questions like this and this.
This morning I've been reading ScuttGu's blog about ASP.NET vNext where he details Model Binding using a SelectMethod that seems to rely on IQueryable for paging and sorting.
Do you think this will force us to reconsider the role IQueryable plays in repositories?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
DDD Repository 应封装数据访问技术细节：
它还负责处理域对象生命周期的中期和结束。 Repository接口属于Domain，应该尽可能基于Ubiquitous Language。除了 DDD 书籍之外，这两篇文章几乎涵盖了设计存储库时需要了解的所有内容：
通用存储库在我看来，在存储库接口上公开 IQueryable 并不是最佳选择。 IQueryable 不是通用语言的一部分。这是一个技术问题，没有领域意义。 Repository 不会封装数据检索，而是会暴露裸数据访问机制，这从根本上违背了 Repository 的初衷。
关于 ASP.NET。这是一个UI框架。为什么要允许 UI 框架影响领域模型的设计？ Microsoft 的示例经常鼓励将 UI 数据网格直接绑定到数据库表之类的事情。或者，最近，控件绑定到所谓的域模型，而它实际上是贫血模型，或者简单地带有获取/设置的哑数据容器。您提到的文章中的引用（我强调了一些）：
我对此的解释是放弃模型和对象，只将数据绑定到 UI。在很多情况下，这可能是一种有效且合理的方法。但由于问题被标记为 DDD，我想说在 DDD 中这被称为 智能 UI 反模式。
DDD Repository should encapsulate data access technicalities:
It is also responsible for handling middle and end of life of domain objects. Repository interface belongs to Domain and should be based on Ubiquitous Language as much as possible. In addition to DDD book, these two articles cover almost everything you need to know when designing repositories:
GenericRepositoryExposing IQueryable on the Repository interface is not optimal in my opinion. IQueryable is not part of Ubiquitous Language. It is a technicality, it has no domain meaning. Instead of encapsulating data retrieval Repository would expose bare data access mechanism, which essentially defeats the purpose of having Repository in the first place.
Regarding ASP.NET. This is a UI framework. Why would you allow UI framework to affect the design of you domain model? Microsoft examples often times encourage things like UI data grid binded directly to your database tables. Or, most recently, controls binded to what is referred to as Domain Model, while it is in fact Anemic Model, or simply dumb data container with gets/sets. The quote from the article that you mention (I put some emphasis):
My interpretation of this is to ditch the model and objects and just bind your data to UI. This is probably a valid and justified approach in a lot of cases. But since the question was tagged as DDD I would say that in DDD this is called Smart UI Anti-Pattern.