问在MVC Web应用程序中跨存储库共享DbContext

EN

问题

在MVC Web应用程序中，跨多个存储库共享EFDbContext的正确方法是什么？这样做是否审慎/有必要，这样做或不这样做的缺点是什么？

背景

假设：

• 应用程序MvcSite(几十个控制器、多个区域等)
• App.Services(服务层，许多服务)
• App.Data(许多存储库等)
• .等为简单起见而不包括在内(EF代码第一次)

研究至今

1. 对请求的DbContext共享/作用域这样，一个请求就有一个由所有存储库共享的DbContext。
2. 在服务层共享/范围您的DbContext-服务维护单个DbContext，并根据需要将其传递给每个存储库。
3. 不要共享DbContext，因为它们很便宜让每个回购都有自己的。

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

根据我的经验，到目前为止，我还没有使用有限存储库。我一直让服务使用一个DbContext并直接修改它，所以我不需要担心这个问题。从单元测试的角度来看，我被告知有限存储库有很大的好处…我们将拭目以待其馀部分是否值得。

我的思想

(1)对请求的DbContext共享/作用域

这很有趣，因为它巧妙地避免了一些开发人员认为是答案的单例上下文的陷阱，但发现DbContext不是这样工作的。但它似乎有一个缺点，因为它假设所有存储库、服务等都将在整个请求中协调一致…这通常不是这样的，对吗？如果一个回购在另一个回购完成其工作之前保存了更改，怎么办(外部(内部)

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

这对我来说更有意义，因为每个服务都应该协调一个特定的工作单元(更低的情况是有意的)。因此，如果在一个请求中使用了多个服务，那么每个服务都有自己的数据库上下文。

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