问在MVC Web App中跨存储库共享DbContext

EN

问题

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

背景

假设：

• App.MvcSite (几十个控制器，多个区域，etc)
• App.Services (服务层，许多services)
• App.Data (许多存储库等))
• ...为简单起见，排除etc (EF代码优先最新版本)

迄今为止的研究

我似乎找到了至少两三个关于SO和interwebs的思想流派。

将您的DbContext共享到请求，以便单个请求在服务层具有由所有needed.

• Do您的DbContext共享的单个 --服务维护单个DbContext并将其作为不共享DbContext传递给每个存储库，因为它们很便宜让每个回购都有自己的。

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

根据我的经验，到目前为止，我还没有使用过有限存储库。我一直让服务使用DbContext并直接更改它，所以我不需要担心这一点。我被告知，从单元测试的角度来看，有限存储库有很大的好处……我们将看看这是否值得做剩下的事情。

我的想法

(1) 将您的DbContext共享到Request /将其作用域

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

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

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

(3) 不共享DbContext，因为它们是廉价的

我一直都是这么做的。实际上，我几乎总是对每个请求只有一个DbContext，因为只有一个服务被调用。有时可能是两个，因为协调工作的控制器调用了两个服务。但考虑到我目前的应用程序，有许多有限的存储库，每个存储库都有自己的上下文，这意味着一个给定的请求可能有3-10个DbContext实例。我假设(也许是错误的)这是有问题的。

重复问题：

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