使用工作单元和存储库模式与实体框架的好处

Question

根据MSDN，DbContext定义为：

  

表示工作单元和存储库模式的组合   并使您能够查询数据库并将更改组合在一起   然后将作为一个单元写回商店。

由于DbContext实现了工作单元和存储库模式，那么为什么我在互联网上找到的ASP.NET tutorial和其他资源证明DbContext使用自定义实现工作单元和存储库模式？这不是多余的吗？

如果不，使用DbContext时创建工作单元和存储库图层的自定义实现有什么好处？ （我可以看到这在测试项目中如何有意义。）

Answer 1

是的，DbContext代表一个工作单元，DbSet代表一个存储库，但有些人会为它们创建一个抽象层。以下是人们可能会这样做的原因：

• 也许他们不希望他们的项目与Entity Framework及其架构紧密耦合。因此，他们将实体框架隐藏在这些抽象背后，以便他们可以将实体框架替换为任何其他ORM，而无需对数据访问层的接口进行任何修改。
• 他们使用存储库来明确某些实体允许哪些操作。 （例如，CustomerRepository可能允许添加和更新客户，但不能删除客户。）另一方面，它使客户端开发人员能够轻松识别某些实体的可用操作。换句话说，他们使用与域语言兼容的命名约定和接口创建存储库。
• 将与数据库相关的操作移动到存储库允许您拦截这些操作并执行日志记录，性能调整或任何其他操作。
• 有些人这样做可以让测试更容易。假设我有一个ICustomerRepository接口，有三种方法。然后我可以轻松地模拟它，而不是用太多方法嘲笑IDbSet<Customer>。
• 最后，有许多 不 创建了对DbContext和DbSet的抽象。他们只是直接使用它们，完全有效。

Answer 2

我知道为时已晚

工作单位： 当您将数据导入和导出数据库时，跟踪您已更改的内容非常重要。同样，您必须插入新对象 创建并删除您删除的任何对象。

您可以在对对象模型进行每次更改时更改数据库，但这会导致大量非常小的数据库调用。

工作单元会跟踪您在业务交易中可能影响数据库的所有操作。

对于存储库模式： 它是数据库中的隔离业务域。

阅读本书（PEAA）