为什么我们在存储库中注入数据库上下文,而不是在存储库类本身内部创建数据库上下文?

时间:2018-11-27 13:43:52

标签: entity-framework design-patterns repository-pattern

存储库模式的目标之一是使业务逻辑与数据访问脱钩。那么为什么数据库上下文没有在存储库类本身中创建而不是由服务层或控制器提供给它呢?

2 个答案:

答案 0 :(得分:0)

您传递上下文是因为您可能有一个跨存储库的事务。上下文是存储库的工作单元。

答案 1 :(得分:0)

只需扩展@Fran在他的回答和评论中所说的话即可。

在大多数情况下,数据库上下文代表您的工作单元。考虑到这一点,至少有两个原因将其注入存储库而不是在存储库中创建。

  1. 在多个存储库中使用相同的上下文
    许多文章说,事务是存储库的责任。但是,在现实世界中,并非每次都是这样。可能需要跨多个存储库进行事务处理。为此,没有比注入它更好的方法了。

  2. 以更高的级别管理上下文(可能是Web中每个请求的上下文),这是存储库无法访问的
    这与上面没有太大区别。许多实现在更高级别管理上下文,而存储库无法访问上下文。每个请求的上下文是流行的示例。在这种情况下,上下文必须以某种方式与存储库分开,并以不同的方式处理。但是,存储库确实需要上下文。所以只需注入即可。

由完整ORM公开的上下文可实现大规模的变更跟踪。为了更好地利用此功能,最好将Context与存储库分开。

想象一下您的存储库调用成功但由于其他文件操作失败而不想刷新的情况。

通过将上下文与存储库分开,可以更好地实现SRP。上下文负责更改跟踪和刷新的责任。存储库保留具有更改的数据在内存中的表示形式,并允许读取/写入此内存中的数据。