Mas*_*oud 4 entity-framework data-access-layer repository unit-of-work dbcontext
的DbContext在EF Code first器具的工作单位和存储库模式为
MSDN网站上说:
DbContext实例表示工作单元和存储库模式的组合,以便它可以用于从数据库进行查询并将更改组合在一起,然后将更改作为一个单元写回到存储中.DbContext在概念上类似于ObjectContext.
这是否意味着使用另一个UoW和Repository抽象(例如IRepository和IUnitOfWor),超过DbContext是错误的？
换句话说,在DbContext上使用另一个抽象层是否会为我们的代码添加任何其他值？
技术独立DAL(我们的域将取决于IRepository和IUnitofWork而不是DbContext)等值
考虑一下 - 你目前有两个强大的ORM,每个都有它的优点和缺点:
此外还有几个微ORM,例如:
为了使事情变得更复杂,有非SQL数据库的客户端/驱动程序,例如:
当然,还需要考虑的另一件事是,是否会有包含模拟数据访问层的测试.
决定是否应该使用UoW/Repository模式应该来自您的项目本身.
如果您的项目是短期的,预算有限,并且除了实体框架和SQL之外您不可能使用其他任何东西,那么引入UoW/Repository抽象层将只会带来您可以用于的额外无意义的开发时间.其他东西或早期完成的项目,并赚取一些额外的现金.
但是,如果项目长期运行并涉及包括连续测试在内的更复杂的开发生命周期,则必须使用UoW/Repository模式.随着现在正在使用的数据库数量和NoSQL运动在.NET生态系统中大量涌现,一旦决定扩展,决定选择ORM和数据库可能会导致严重的重构(即使用MongoDb扩展比使用它更便宜SQL,所以您的客户可能会突然要求您将所有内容移至MongoDb).由于双方正在不断变换,并且正在实施新的想法(例如组合图形+文档数据库),没有人能够在1年后很好地声明哪个数据库将成为您项目的最佳选择.
这个问题没有布尔答案.
这只是我的观点,它来自开发人员,他们从事短期和长期项目.
| 归档时间： |
|
| 查看次数： |
597 次 |
| 最近记录： |