我已经读过 DbContext 对象应该创建为 InstancePerHttpRequest，而不是 SingleInstance，因为它的线程不安全性质，并且它可能在请求之间消耗太多资源，这很有意义。但我正在使用使用 DbContext 实例的 Repository 对象。我应该将它们设为 InstancePerHttpRequest 还是将它们设为 SingleInstance 并使用 DependencyResolver 来获取当前的 DbContext。
对于 Autofac（或任何其他 DI）、DbContext、存储库和基于服务的 Web 应用程序，最好的对象创建设计是什么？
另一个问题是，为每个 Web 请求（如请求中的 10-15 个）为每个存储库或服务创建不同的 DbContext 对象有多昂贵？
DbContext 实例化非常便宜，所以我不会太担心获得新的时间。
我在 DbContext 的范围内遇到的问题与其说是线程安全，不如说是查询隔离。因为任何人都可以调用保存更改并将整个对象图提交到数据库，所以您要确保仅在具有特定更改的上下文中调用它。
关于 DbContext 要了解的另一个关键是，它跟踪的项目越多，性能就会下降。这意味着如果你将它绑定在单例中，你可能会导致一些非常严重的性能问题。（有一些方法可以解决这个问题，但知道我在这里的帖子真的很好）
我个人对 Web 应用程序的偏好是将上下文和存储库绑定在 HttpRequest 的范围内。这意味着只有您当前的请求线程才能保存更改，并且还限制了您可能跟踪的项目数量。
抱歉，我的一些术语可能与 autofac 不匹配，因为我自己是一个 ninject 人:)
DbContext is your Unit of Work, and is thus never suited for SingleInstance scope. Treat it as such. Sometimes a request maps directly to a UoW, but not necessarily always. Consider this before you scope it to the request.
DbContext is cheap to instantiate, so I would design it such that each service gets its own instance. 10-15 per request is fine, unless you encounter a problem you can trace back to the number of DbContexts instantiated. Anything else smells like pre-mature optimization to me.
I tried to stay DI agnostic, as I primarily use StructureMap.