asp.net-mvc – 在MVC Web应用程序中的存储库中共享DbContext

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

背景

承担：

> App.MvcSite(几十个控制器,多个区域等)
> App.Services(服务层,许多服务)
> App.Data(许多存储库等)
> …等排除简单(EF Code First latest)

研究至今

我似乎在SO和互联网上至少找到了两三个思路.

>将DbContext共享/覆盖到请求,以便单个请求具有所有存储库共享的单个DbContext.
>在服务层共享/覆盖您的DbContext – 服务维护一个单一的DbContext,并根据需要将其传递到每个存储库.
>不要分享一个DbContext,因为它们很便宜,每个Repo都有自己的.

在一个小型网站上,这是一个非问题,这就是为什么大多数MS和社区示例根本就没有解决这个问题.

根据我迄今为止的经验,我没有使用有限的资料库.我一直有服务使用DbContext,并直接改变它,所以我不需要担心这一点.我被告知,从单元测试的角度来看,有限的存储库有很大的好处,我们将看看它是否能够使其余部分成为可能.

我的想法

(1) Share/scope your DbContext to the Request

这是有趣的,因为它巧妙地避免了一些开发人员认为的答案的单例上下文的缺陷,但是发现DbContext不起作用.但是它似乎有一个缺点,它假定所有的存储库,服务等将在整个请求中协调一致 – 这通常不是这样的,对吗？如果在另一个完成工作之前由一个repo保存更改. (外(内(内)))

(2) Share/scope your DbContext at the service layer

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

(3) Do not share a DbContext,since they are cheap

这是我一直做的事情,实际上我几乎总是只有一个DbContext每个请求,因为只有一个服务被调用.有时可能是两个,因为两个服务是由协调工作的控制者召集的.但是,鉴于我目前的应用程序,有许多有限的存储库,每个存储库都有自己的上下文意味着一个给定的请求可能具有3-10个DbContext实例.我假设(也许不正确)这是有问题的.

重复的问题：

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