在 ASP.NET MVC WebAPI 中用于只读目的的静态 DbContext 对象答案

【问题标题】：A static DbContext object for read-only purposes in ASP.NET MVC WebAPI在 ASP.NET MVC WebAPI 中用于只读目的的静态 DbContext 对象
【发布时间】：2013-11-03 02:15:32
【问题描述】：

出于性能优化的原因，我正在重构我的 ASP.NET MVC 4 WebAPI 项目。在我的控制器代码中，我在上下文（DbContext、EF6）中搜索实体。有几千个这样的实体，每小时添加新的实体（即“缓慢”），它们很少被删除（我不在乎是否仍然在上下文的缓存中找到已删除的实体！）并且永远不会修改。

在阅读了this question、this one 的答案以及更多讨论之后，我仍然不确定将单个静态 DbContext 用于上述目的是一个坏主意 - 一个 DbContext 从不更新数据库。

性能方面，我不担心实例化成本，而是担心如果为每个请求创建 DbContext，缓存请求实体的无用。我还使用了二级缓存，这使得上下文的持久性更加敏锐。

我的问题是： 1.无论具体实现如何，在我的情况下，“静态” DbContext 是一个有效的解决方案吗？ 2. 如果是这样，实现这种 DbContext 的最合适的方式是什么？ 3.我是否应该定期“刷新”上下文以清除缓存以防止 if 变得太大？

【问题讨论】：

如果您查看Dictionary <TKey, TValue> 的文档，您会发现它声称只有在读取时才具有线程安全性。 DbContext 文档中缺少这些声明，因此我们必须假设它不是线程安全的，即使在只读场景中，即使您确保在单线程初始化阶段只查询数据库一次。

标签： entity-framework dependency-injection asp.net-web-api

【解决方案1】：

DbContext 在您获取/查询数据时缓存实体实例。它确保不同的查询返回相同的数据映射到相同的实体（基于类型和 id）。否则，如果您在不同的对象实例中修改相同的实体，上下文将不知道哪个具有正确的数据。因此，静态 DbContext 会随着时间的推移而崩溃，直到进程崩溃。

DbContexts 应该是短暂的。 Request.Properties 是在 Web API 中保存它的好地方（映射到 IIS 中的 HttpContext.Items）。

【讨论】：

正如我所说，实体永远不会在任何地方修改，否则我不会考虑使用静态替代方案。如果您考虑到这一点，并假设 DbContext 缓存确实可以提高性能（我正在寻找这些实体大约每秒 1000 次），您还会认为静态 DbContext 是个坏主意吗？
如果您只读取/查询数据，实体仍会缓存在上下文中，因为它不知道您以后是否要修改数据。没有办法禁用它。
NHibernate 对这些场景有 IStatelessSession 但实体框架没有类似的东西。编辑：实际上您可以使用“.AsNoTracking()”方法关闭查询跟踪。但请确保不要通过 id 获取实体。由于潜在的线程问题，我仍然不会这样做，并且仍然可以缓存一些数据。
Dmitry，更改跟踪显然会被禁用。当我只想通过尽可能多地使用缓存来优化缓存时，为什么我想禁用缓存？
如果数据库可以适应内存而不会使工作进程膨胀，它可能会工作。我还会研究数据库上下文中的查询是否是线程安全的，或者您可能需要使用锁定。