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