DbContext 是一项昂贵的操作吗？答案

【问题标题】：Is DbContext an expensive operation?DbContext 是一项昂贵的操作吗？
【发布时间】：2015-08-29 19:27:09
【问题描述】：

在 C# MVC EF 框架中，我看到很多示例在需要插入或查询时简单地创建一个新的DbContext，然后关闭/释放它（许多使用“使用”来自动关闭/释放）。

对此进行了一些搜索但找不到好的答案，但是创建DbContext 是一种非常便宜且快速的操作吗？

例如，考虑一个典型的 MVC 应用程序，在页面上它有许多“组件”，例如页眉、侧边栏、主要内容等，并且在一个不平凡的设置中，每个组件都有自己的单独的逻辑和代码——我是否想在每个组件中创建一个新的DbContext？（如果是，系统会自动缓存查询结果吗？——例如，一个常见的用例是，在每个组件中，它需要查询数据库以获取当前站点范围的设置，即表）。

【问题讨论】：

这是你容易测试和观察到的东西。试试看吧！
@Cubicle.Jockey 他应该在哪里做呢？控制器似乎是个好地方。
我没有将其发布为答案，因为我在 MSDN 上找不到原始页面，但是，准备好有效地创建和销毁上下文，创建上下文的唯一昂贵部分是底层数据库连接和 EF 将管理它，当您销毁上下文时它不会关闭它，它有一个管理它们的内部池
参见 msdn.microsoft.com/en-us/library/vstudio/… 和 oakleafblog.blogspot.de/2008/08/… ：只有第一次启动上下文是昂贵的，重新创建上下文非常快，被认为是好的做法。
如果你这么关注性能，不要使用实体框架:)

标签： c# asp.net-mvc entity-framework

【解决方案1】：

如“Performance Considerations for Entity Framework 4, 5 and 6”第 9.3 节（强调我的）中所述：

实体框架的上下文旨在用作短期实例，以提供最佳性能体验。 上下文预计将是短暂的并被丢弃，因此已实现非常轻量级并尽可能重用元数据。在 Web 场景中，记住这一点很重要，并且上下文的持续时间不会超过单个请求的持续时间。同样，在非 Web 场景中，应根据您对实体框架中不同级别缓存的理解丢弃上下文。 一般而言，应避免在应用程序的整个生命周期中使用上下文实例，以及每个线程的上下文和静态上下文。

【讨论】：

【解决方案2】：

您可以使用注入，例如通过 Unity，这将允许在请求进入时创建 DbContext 的单个实例并将其注入到需要的地方。使用 Unity，我相信您可以指定是否为每个请求创建一个实例，或者是否每次都创建一个新实例。

在任何需要的地方创建 DbContext 并不会很慢，但这需要一点常识，所以如果可以的话，重用你已有的 DbContext，如果你专注于与数据库查询相关的性能，那么会有总是使用任何 ORM 的开销。这是一个方便的权衡。

我还建议使用 Glimpse 之类的工具，它可以让您查看用于呈现页面的所有查询和连接，包括 ajax 查询，并让您对正在发生的事情有一个很好的了解。有时可能有点吓人！

【讨论】：