mar*_*c_s 57 architecture repository-pattern data-structures
在.NET(Winforms,WPF,ASP.NET)上创建更大规模的企业级应用程序时,我看到两个主要的"思想流派".
有些人使用"存储库模式",它使用知道如何获取,插入,更新和删除对象的存储库.这些对象相当"愚蠢",因为它们不一定包含大量逻辑 - 例如,它们或多或少是数据传输对象.
另一个阵营使用我所谓的"智能"业务对象,它们知道如何加载自己,并且它们通常具有Save(),可能是Update()甚至Delete()方法.在这里,你真的不需要任何存储库 - 对象本身知道如何加载和保存自己.
最大的问题是:你使用或更喜欢哪种？为什么？
您是否在所有应用中使用相同的方法,或者您在选择一种方法时是否有任何特定标准？如果是的话 - 这些标准是什么？
我不是想在这里开始一场火焰战 - 只是试图找出每个人对此的看法以及你的观点是什么,以及为什么你使用一种(或两种)模式而不是另一种.
感谢任何建设性的意见!
Joh*_*ing 39
由于单一责任原则,我使用存储库模式.我不希望每个单独的对象必须知道如何保存,更新,删除自己,这可以由一个单一的通用存储库来处理
thi*_*ing 16
存储库模式不一定会导致愚蠢的对象.如果对象在Save/Update之外没有逻辑,那么你可能在对象之外做了太多.
理想情况下,您永远不应该使用属性从对象获取数据,计算内容并将数据放回对象中.这是封装的突破.
因此,除非您将简单的DTO对象与CRUD操作一起使用,否则对象不应该是贫血的.
然后将持久性问题与对象关注点分开是一种获得单一责任的好方法.
| 归档时间： |
|
| 查看次数： |
6144 次 |
| 最近记录： |