Entity Framework断开连接场景下缓存是否毫无用处？

我在自己的应用里用Entity Framework，想通过缓存数据库查询结果来提升性能——意思是除了首次查询，之后都用EF的断开连接实体。但处理断开连接实体时必须判断实体是不是新的，代码示例如下：

public static void InsertOrUpdate(BloggingContext context, Blog blog)
{
    // 查询数据库判断实体是否存在
    var existingBlog = context.Blogs.Find(blog.BlogId); 

    if (existingBlog == null)
    {
        context.Add(blog);
    }
    else
    {
        context.Entry(existingBlog).CurrentValues.SetValues(blog);
    }

    context.SaveChanges();
}

既然不管怎样都得查数据库，那我做的缓存尝试是不是完全没用？

缓存不是完全没用，得分场景具体分析：

• 读多写少场景收益明显：如果你的应用大部分操作是读取数据，只有少量更新/插入操作，缓存依然能大幅降低数据库的读请求压力。比如用户频繁浏览博客列表，缓存住列表数据后，不用每次都查库，只有在更新单篇博客时才需要查一次数据库判断存在性，这种情况下缓存的价值依然很大。

• 优化实体存在性判断逻辑：你当前用Find查库判断实体是否存在，其实可以换个思路——如果业务上能通过规则直接判断（比如BlogId是客户端生成的GUID、实体带有“新增状态”标记、创建时间为空等），就能避免这次查库，直接基于缓存或业务规则处理，这样缓存的作用就能最大化。

• 调整缓存粒度适配业务：如果缓存的是单实体，更新时确实需要查库校验，但如果缓存的是聚合数据、只读视图这类不直接参与更新判断的内容，缓存依然能在读路径上持续发挥性能提升作用。

另外，也可以考虑使用EF的二级缓存框架，这类框架能自动缓存查询结果，同时在数据更新时自动失效相关缓存，不用手动处理缓存一致性，能进一步简化缓存逻辑并提升性能。

内容的提问来源于stack exchange，提问作者Veverke