DbContext在 EF Code first工具Unit of Work和 Repository模式为
MSDN网站说:
A DbContext instance represents a combination of the Unit Of Work and Repository patterns such that it can be used to query from a database and group together changes that will then be written back to the store as a unit. DbContext is conceptually similar to ObjectContext.
这是否意味着在 DbContext 上使用另一个 UoW 和 Repository 抽象(例如 IRepository 和 IUnitOfWor)是错误的？
换句话说，在 DbContext 上使用另一个抽象层是否会为我们的代码添加任何附加值？
技术独立 DAL 等值(我们的域将取决于 IRepository 和 IUnitofWork 而不是 DbContext)
最佳答案
考虑一下 - 您目前有两个强大的 ORM，每个都有其优缺点:
此外，还有更多的微型 ORM，例如:
更复杂的是，有非 SQL 数据库的客户端/驱动程序，例如:
当然，始终必须考虑的另一件事是是否会有包括模拟数据访问层的测试。
是否应该使用 UoW/Repository 模式的决定应该来自您的项目本身。
如果您的项目是短期的，预算有限，并且除了 Entity Framework 和 SQL 之外您不太可能使用其他任何东西，那么引入 UoW/Repository 抽象层只会花费您额外的毫无意义的开发时间，您可以在其他东西或更早完成的项目并赚取了一些额外的现金。
然而，如果项目是长期运行的并且涉及更复杂的开发生命周期，包括持续测试，那么 UoW/Repository 模式是必须的。随着现在使用的数据库数量和 NoSQL 运动在 .NET 生态系统中的大量涌入，一旦您决定向外扩展(即使用SQL，因此您的客户可能会突然要求您将所有内容移至 MongoDb)。由于现在双方不断变化，并且正在实现新的想法(例如组合图 + 文档数据库)，没有人可以很好地说明从现在起 1 年后哪个数据库将是您项目的最佳选择。
这个问题没有 bool 答案。
这只是我的观点，它来自从事短期和长期项目的开发人员。
关于entity-framework - 在 DbContext 上使用抽象层，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24218750/