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

Question

根据MSDN,DbContext定义为:

表示工作单元和存储库模式的组合,使您可以查询数据库并将更改组合在一起,然后将这些更改作为一个单元写回到存储中.

既然DbContext实现了工作单元和存储库模式,那么为什么我在Internet上找到的ASP.NET教程和其他资源演示了如何使用DbContext工作单元和存储库模式的自定义实现？这不是多余的吗？

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

Answer 1

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

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

Answer 2

我知道已经太晚了

对于工作单元：当您从数据库中提取数据时，跟踪您所做的更改非常重要。同样，您必须插入您创建的新对象并删除您删除的任何对象。

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

工作单元跟踪您在业务事务期间所做的所有可能影响数据库的事情。

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

读一本书（PEAA）