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