每个请求缓存实体框架DbContexts

Question

我有几个基于System.Entity.Data.DbContext的类.它们在Web应用程序的不同端部被多次使用请求 - 实例化它们是否昂贵？

我在HttpContext.Current.Items中缓存了它们的副本,因为每个请求都有几个副本它们感觉不对,但我现在发现它不会自动从HttpContext处理掉.请求.在我开始编写代码来处理它之前(在Application_EndRequest中),我认为我已经重新考虑了这种情况,因为如果我应该在需要它们的地方实例化它们并在那里处理它们,那么实际上没有必要缓存它们.

互联网上已经提出了与此类似的问题,但我似乎无法找到一个完全回答我的问题的问题.对不起,如果我正在重复某人.

更新

我发现在这篇博客文章中处理上下文可能并不重要,但我仍然有兴趣听到它们首先实例化是否昂贵.基本上,幕后有很多EF魔法,我想避免经常这么做吗？

Answer 1

最好的办法是使用IoC容器来管理生命周期 - 它们非常非常擅长,这是一种非常常见的情况.具有使动态调用变得容易的附加优势 - 意味着对样式表的请求不会创建DB上下文,因为它在BeginRequest()中是硬编码的.

Answer 2

为了完整起见，我正在回答我自己的问题。

此答案提供了有关此问题的更多信息。

综上所述，实例化 DbContext 的成本并没有那么高，所以不用担心。

此外，您实际上也不需要担心数据上下文的处理。您可能会注意到 ScottGu 在他的示例中没有（他通常将上下文作为控制器上的私有字段）。 这个答案提供了 Linq to SQL 团队提供的一些关于处理数据上下文的好信息，并且这篇博文也对这个主题进行了扩展。