DbContext是一个昂贵的操作吗?
本文关键字：操作 一个 DbContext | 更新日期: 2023-09-27 18:10:15
在c# MVC EF框架中，我看到了很多例子，只要需要插入或查询，就简单地创建一个新的DbContext，然后关闭/释放它(许多人使用"using"来自动关闭/释放)。
对此进行了一些搜索，但找不到一个好的答案，但是创建DbContext是一个非常便宜和快速的操作吗?
例如，考虑一个典型的MVC应用程序，在页面上它有许多"组件"，如标题，侧边栏，主要内容等，并在一个非平凡的设置，每个组件将有自己的个人逻辑和代码-我想创建一个新的DbContext在每个这些组件?(如果是，系统是否会自动缓存查询结果?)—例如，一个常见的用例是，在每个组件中，它需要查询数据库中当前站点范围的设置，这是表中的同一行)。
正如"实体框架4,5和6的性能考虑"第9.3节所述:
为了提供最佳的性能体验，实体框架的上下文被用作短期实例。上下文被期望是短暂的，并且被丢弃，因此被实现为非常轻量级的，并且在可能的情况下重用元数据。在web场景中，记住这一点很重要，不要让上下文超过单个请求的持续时间。类似地，在非web场景中，上下文应该基于你对实体框架中不同级别缓存的理解而被丢弃。一般来说，应该避免在应用程序的整个生命周期中使用上下文实例，以及每个线程的上下文和静态上下文。
你可以使用注入，就像通过Unity一样，这将允许在请求进来时创建DbContext的单个实例，并在需要的地方注入。使用Unity，我相信你可以指定是每个请求都创建一个实例，还是每次都创建一个新实例。
在你需要的任何地方创建DbContext都不是很慢，但是这有一点常识，所以如果可以的话重用一个你已经拥有的，如果你专注于与数据库查询相关的性能，那么使用任何ORM总是会有开销。这是一种方便的权衡。我还建议使用像Glimpse这样的东西，它可以让你看到渲染页面时使用的所有查询和连接，包括ajax查询，并让你对正在发生的事情有一个很好的概述。有时会有点可怕!