ASP.NET MVC多层应用EF+MemoryCache遇ObjectContext已释放错误求解决方案

你遇到的这个问题我之前也踩过坑！核心原因很简单：你缓存的IQueryable<Category>并不是实际的数据，而是一个还没执行的查询表达式。

当你第一次调用_db.Categories时，EF并没有立刻去数据库查数据——这是EF的延迟执行特性。等你第一次请求结束，你的_db（ObjectContext/DbContext）被释放后，第二次从缓存里取出这个IQueryable并试图使用它时，它还想着去找已经被销毁的上下文要数据库连接，自然就抛出那个错误了。

下面给你两个最实用的解决方案：

方案1：缓存已执行的实体集合（快速解决） #

直接把IQueryable转换成已经加载到内存的集合（比如List），这样缓存的是实际的数据，而不是依赖上下文的查询对象：

public IQueryable<Category> GetAll() {
    var cacheKey = string.Format("{0}_{1}", "CategoryRepository", "GetAll");
    var isExists = _cache.Contains(cacheKey) && Const.CacheIsActive;
    if (isExists) {
        // 把缓存的List转成IQueryable返回，不需要再碰数据库
        return _cache.Get<List<Category>>(cacheKey).AsQueryable();
    } else {
        // 用ToList()立即触发数据库查询，把数据加载到内存
        var categoryList = _db.Categories.ToList();
        _cache.Add(cacheKey, categoryList);
        return categoryList.AsQueryable();
    }
}

这样修改后，缓存的是实打实的Category对象列表，后续从缓存取出后，AsQueryable()只是给集合套个IQueryable的壳，完全不需要和数据库交互，也就不会用到已经释放的上下文了。

方案2：使用业务对象（DTO），更符合多层架构设计 #

这也是你提到的思路，其实这是更规范的做法，尤其适合ASP.NET MVC这种多层架构：

把EF生成的实体类（Category）转换成独立的业务对象（比如叫CategoryDto），缓存这个DTO集合。这样不仅能彻底解决上下文依赖的问题，还能实现各层之间的解耦，隐藏数据库层的细节。

先定义业务对象：

public class CategoryDto {
    public int Id { get; set; }
    public string Name { get; set; }
    // 其他需要的属性，只保留业务层需要的字段就行
}

然后修改Repository的方法：

public IQueryable<CategoryDto> GetAll() {
    var cacheKey = string.Format("{0}_{1}", "CategoryRepository", "GetAll");
    var isExists = _cache.Contains(cacheKey) && Const.CacheIsActive;
    if (isExists) {
        return _cache.Get<List<CategoryDto>>(cacheKey).AsQueryable();
    } else {
        // 从EF实体映射到DTO，同时用ToList()立即执行查询
        var dtoList = _db.Categories
                         .Select(c => new CategoryDto {
                             Id = c.Id,
                             Name = c.Name
                             // 映射其他需要的属性
                         })
                         .ToList();
        _cache.Add(cacheKey, dtoList);
        return dtoList.AsQueryable();
    }
}

这个方案的好处：

• 彻底脱离EF上下文的依赖，缓存的是纯POCO对象，不会有任何延迟加载或上下文释放的问题。
• 符合分层架构的职责：数据访问层负责数据获取和映射，业务层处理逻辑，展示层用DTO，避免各层之间的耦合。

额外注意事项 #

• 缓存失效要处理：当Category数据新增、修改、删除时，记得删除对应的缓存键，不然用户会看到旧数据。
• 避免缓存代理对象：如果你的Category是EF的动态代理类（比如开了延迟加载），即使缓存List也可能有问题，最好转换成DTO，或者在DbContext里关闭ProxyCreationEnabled。
• 多实例场景的缓存同步：如果你的应用是多实例部署（比如负载均衡），MemoryCache是进程内的，各实例缓存不会同步，这种情况可以考虑用分布式缓存比如Redis。

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