使用DbContext的抽象层

Question

EF Code First 中的 DbContext 实现了 Unit of Work 和 Repository 模式，正如MSDN 网站所说：

一个 DbContext 实例表示 Unit Of Work 和 Repository 模式的组合，使其可以用于从数据库中查询并将更改分组，然后作为一个单元写回存储。DbContext 在概念上类似于 ObjectContext。

这是否意味着在 DbContext 上使用另外的 UoW 和 Repository 抽象（例如 IRepository 和 IUnitOfWor）是错误的？

换句话说，在 DbContext 上使用另一层抽象是否为我们的代码增加了任何附加值？

例如，技术无关的 DAL（我们的域将依赖于 IRepository 和 IUnitofWork 而不是 DbContext）。

- Masoud

Answer 1

考虑这个问题——目前有两个强大的ORM，它们各自有优缺点：

- Entity Framework - NHibernate 此外还有一些微型ORM，例如：

- Dapper - Massive - PetaPoco - ...

为了让事情更加复杂，还有针对非SQL数据库的客户端/驱动程序，例如：

- MongoDb的C#驱动程序 - Redis的StackExchange驱动程序 - ...

当然，必须考虑的另一件事情是是否会进行测试，包括模拟数据访问层。

是否应该使用UoW/Repository模式取决于项目本身。

如果您的项目是短期的，预算有限，并且您不太可能使用除Entity Framework和SQL之外的任何东西，那么引入UoW/Repository抽象层只会让你花费额外的无意义开发时间，而这些时间本可以用在其他事情上，或者提前完成项目并获得一些额外的现金。

然而，如果项目是长期运行的，并涉及更复杂的开发生命周期，包括持续测试，则UoW/Repository模式是必须的。由于现在正在使用大量数据库，并且NoSQL运动在.NET生态系统中大力推广，因此选择ORM和数据库可能会在决定扩展时导致严重的重构（例如，使用MongoDb进行扩展比使用SQL便宜得多，因此您的客户可能突然要求您将所有内容移动到MongoDb）。由于双方不断地转移，新想法正在实施（例如组合图形+文档数据库），因此没有人能够对这个问题做出好的陈述。哪种数据库在一年后将是最佳选择。

这个问题没有确定的答案。

这只是我的观点，来自于同时从事短期和长期项目开发的开发人员。

- Admir Tuzović