Net Core：DbContext是否需要MemoryCache或Redis？

Question

我们在SQL Server数据库中有多个查找表。表在应用程序下拉菜单中使用。

地址类型：

• 首页
• 商业

产品型号：

• 书籍
• 食品
• 电子

[而不是持续读取数据库查找表，团队希望应用MemoryCache或Redis Cache（以减少数据库负载并提高内存性能）。但是，我们了解到Entity Framework Core DbContext已经具有缓存。

因此，在这种情况下，缓存查找表中是否会有任何值，如果经过一定数量的读取后，DbContext已经这样做了吗？是否会在MemoryCache/Redis之上添加更多的DbContext缓存代码帮助？还是不必要的层？

Answer 1

与Microsoft一样，EF Core 2.0，EF Core仅支持第一级缓存，也就是说，当实体由于执行查询而实现时，它存储在与实体框架上下文关联的内存缓存中（又名System.Data.Entity.DbContext类）

EF Core的第一级缓存机制可以提高性能，但是，请考虑以下情况：实体的记录级别在数据库级别发生了变化，而我们仍在处理Entity Framework上下文中实体的本地缓存副本。因此这会导致我们得到错误结果集的情况。

因此，解决此问题的方法是将那些实体与上下文分离，这实际上意味着将其从一级缓存中删除，也称为逐出缓存项。分离完成后，可以再次获取实体，这将确保从数据库中读取新数据。

因此，我们看到EF Core的开箱即用（OOB）一级缓存机制远非完美。这会导致笨拙的代码容易出错，并且从长远来看，很有可能使代码库变得混乱且难以维护。 EF Core OOB一级缓存机制的其他一些缺点是：

• 随着更多的对象及其引用被加载到内存中，上下文的内存消耗可能呈指数级增长，具有讽刺意味的是，这导致了性能问题，为此，我们首先开始使用EF核心一级缓存。
• 当不需要上下文时未正确处理上下文时，可能的内存泄漏。
• 并发相关问题的可能性随着查询和更新数据之间的时间间隔的增加而增加。

因此，您可以看到需要扩展分布式应用程序，因此强烈建议您使用缓存提供程序。