.net - 将工作单元和存储库模式与 Entity Framework 结合使用的好处

Question

根据MSDN ，DbContext 定义为:

Represents a combination of the Unit-Of-Work and Repository patterns and enables you to query a database and group together changes that will then be written back to the store as a unit.

既然DbContext实现了工作单元和存储库模式，那么为什么会这样ASP.NET tutorial我在互联网上找到的其他资源演示了如何使用 DbContext 以及工作单元和存储库模式的自定义实现？这不是多余的吗？

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

Answer 1

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

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