在这个问题或讨论中没有真正解决的一件事是DbContext不能取消更改的事实。您可以提交更改，但不能清除更改树，因此如果您使用了每个请求上下文，那么无论出于何种原因需要丢弃更改，都是不走运的。

Personally I create instances of DbContext when needed - usually attached to business components that have the ability to recreate the context if required. That way I have control over the process, rather than having a single instance forced onto me. I also don't have to create the DbContext at each controller startup regardless of whether it actually gets used. Then if I still want to have per request instances I can create them in the CTOR (via DI or manually) or create them as needed in each controller method. Personally I usually take the latter approach as to avoid creating DbContext instances when they are not actually needed.

这也取决于你从哪个角度看问题。对我来说，每个请求实例从来没有意义。DbContext真的属于Http Request吗?就行为而言，这是错误的地方。您的业务组件应该创建上下文，而不是Http请求。然后，您可以根据需要创建或丢弃业务组件，而不必担心上下文的生命周期。

我很确定这是因为DbContext根本不是线程安全的。所以分享从来不是个好主意。

实体框架需要特别注意的另一个问题是，当组合使用创建新实体、延迟加载，然后使用这些新实体时(从相同的上下文中)。如果你不使用IDbSet。创建(vs只是新建)，当它从创建它的上下文检索时，对该实体的惰性加载将不起作用。例子:

 public class Foo {
     public string Id {get; set; }
     public string BarId {get; set; }
     // lazy loaded relationship to bar
     public virtual Bar Bar { get; set;}
 }
 var foo = new Foo {
     Id = "foo id"
     BarId = "some existing bar id"
 };
 dbContext.Set<Foo>().Add(foo);
 dbContext.SaveChanges();

 // some other code, using the same context
 var foo = dbContext.Set<Foo>().Find("foo id");
 var barProp = foo.Bar.SomeBarProp; // fails with null reference even though we have BarId set.

我喜欢它的地方在于，它将工作单元(正如用户看到的那样——即页面提交)与ORM意义上的工作单元对齐。

因此，您可以使整个页面提交都是事务性的，如果您公开CRUD方法，并且每个方法都创建一个新的上下文，则无法做到这一点。

这里没有一个答案能真正回答这个问题。OP并没有询问单例/每个应用程序的DbContext设计，他询问了每个(web)请求的设计以及可能存在的潜在好处。

我会参考http://mehdi.me/ambient-dbcontext-in-ef6/，因为Mehdi是一个很棒的资源:

Possible performance gains. Each DbContext instance maintains a first-level cache of all the entities its loads from the database. Whenever you query an entity by its primary key, the DbContext will first attempt to retrieve it from its first-level cache before defaulting to querying it from the database. Depending on your data query pattern, re-using the same DbContext across multiple sequential business transactions may result in a fewer database queries being made thanks to the DbContext first-level cache. It enables lazy-loading. If your services return persistent entities (as opposed to returning view models or other sorts of DTOs) and you'd like to take advantage of lazy-loading on those entities, the lifetime of the DbContext instance from which those entities were retrieved must extend beyond the scope of the business transaction. If the service method disposed the DbContext instance it used before returning, any attempt to lazy-load properties on the returned entities would fail (whether or not using lazy-loading is a good idea is a different debate altogether which we won't get into here). In our web application example, lazy-loading would typically be used in controller action methods on entities returned by a separate service layer. In that case, the DbContext instance that was used by the service method to load these entities would need to remain alive for the duration of the web request (or at the very least until the action method has completed).

记住，也有缺点。这个链接包含了许多关于这个主题的其他资源。

我把这篇文章贴出来，以防别人偶然发现这个问题，并没有被那些并没有真正解决这个问题的答案所吸引。

我同意之前的观点。可以说，如果你打算在单线程应用中共享DbContext，你将需要更多的内存。例如，我在Azure上的web应用程序(一个额外的小实例)需要另外150mb的内存，而我每小时大约有30个用户。

这是一个真实的例子:应用程序已经在中午12点部署