在这个问题或讨论中没有真正解决的一件事是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请求。然后，您可以根据需要创建或丢弃业务组件，而不必担心上下文的生命周期。

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

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

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

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

微软有两个相互矛盾的建议，许多人以完全不同的方式使用dbcontext。

一个建议是“Dispose DbContexts as soon as possible” 因为DbContext激活会占用有价值的资源，比如db 连接等等…… 另一种是每个请求一个DbContext 推荐的

这些相互矛盾，因为如果你的Request做了很多与Db无关的事情，那么你的DbContext就会被毫无理由地保留。 因此，当你的请求只是等待随机的东西完成时，让你的DbContext保持活跃是浪费…

所以很多遵循规则1的人在他们的“存储库模式”中有他们的DbContext，并为每个数据库查询创建一个新的实例，即每个请求X*DbContext

它们只是尽快获取数据并处理上下文。 许多人认为这是一种可以接受的做法。 虽然这有占用你的db资源的最低时间的好处，但显然牺牲了所有的UnitOfWork和缓存糖果EF提供。

保持DbContext的一个多用途实例最大限度地提高了缓存的好处，但由于DbContext不是线程安全的，每个Web请求都运行在它自己的线程上，每个请求的DbContext是你能保持的最长时间。

所以EF的团队建议每个请求使用1 Db Context，这显然是基于这样一个事实:在一个Web应用程序中，一个UnitOfWork最有可能是在一个请求中，这个请求有一个线程。所以每个请求一个DbContext就像UnitOfWork和缓存的理想好处。

但在很多情况下，情况并非如此。 我认为记录一个单独的UnitOfWork，因此有一个新的DbContext后请求记录在异步线程是完全可以接受的

最后，DbContext的生命周期被限制在这两个参数上。UnitOfWork和Thread

在这个问题或讨论中没有真正解决的一件事是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根本不是线程安全的。所以分享从来不是个好主意。