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