在MVC Web App中的资源库中共享DbContext?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (46)

我似乎在SO和Interwebs上至少找到了两三个学派。

  1. 将你的DbContext共享/范围到请求,以便单个请求具有由所有存储库共享的单个DbContext。
  2. 在服务层共享/范围您的DbContext - 服务维护一个DbContext并根据需要将其传递给每个存储库。
  3. 不要共享一个DbContext,因为它们很便宜,让每个Repo都有它自己的。

在一个小网站上,这是一个非问题,这就是为什么大多数MS和社区例子甚至没有解决这个问题。

根据我迄今为止的经验,我没有使用有限的存储库。我一直有服务使用DbContext并直接更改它,所以我不需要担心这一点。我被告知从单元测试的角度来看有限的存储库有很大的好处,我们会看看它是否会让其余的值得。

我的想法

(1)将您的DbContext分享/范围到请求

这很有趣,因为它巧妙地避免了一些开发人员认为是答案的单例上下文的缺陷,但是发现DbContext不能这样工作。但它似乎有一个缺点,它假定所有的存储库,服务等将在整个请求中协调一致......通常情况并非如此,对吗?如果在一个回购协议完成其工作之前保存更改,该怎么办?(外(内(内)))

(2)在服务层共享/范围您的DbContext

这对我来说更有意义,因为每项服务都应该协调一个特定的工作单位(小写意向)。所以如果在一个请求中使用了多个服务,那么每个服务都有自己的上下文到数据库是合适的(如果不是必需的话)。

(3)不要共享DbContext,因为它们很便宜

这是我一直这样做的方式......实际上,我几乎总是每个请求只有一个DbContext,因为只有一个服务被调用。有时候可能是两个,因为两个服务是由协调工作的管理员调用的。但鉴于我目前的应用程序,有许多有限的存储库,每个存储库都有自己的上下文,意味着给定的请求可能有3-10个DbContext实例。我认为(也许不正确)这是有问题的。

重复这个问题:

在MVC Web应用程序中跨多个存储库共享EF DbContext的正确方法是什么?是否谨慎/必要这样做,做或不做这样做的陷阱是什么?

提问于
用户回答回答于
用户回答回答于

我会在前两个选项之间进行组合,并且关于你采取第一个选项,不要让存储库保存任何更改(这不是建议的做法,Martin Fowler说他自己),为此他介绍了工作单元模式。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励