mvc3 OutputCache RemoveOutputCacheItem RenderAction

Кэш для дочерних действий хранится в атрибуте OutputCacheAttribute. Свойство ChildActionCache. Проблема в том, что API, генерирующий идентификаторы дочерних действий и сохраняющий их в этом объекте, не является общедоступным (ПОЧЕМУ Microsoft??). Поэтому, если вы попытаетесь перебрать объекты в этой коллекции, вы обнаружите, что она также будет содержать кэшированное значение для вашего дочернего действия, но вы не сможете идентифицировать его, если не перепроектируете алгоритм, используемый для генерации ключей, который выглядит что-то вроде этого (как видно с Reflector):

internal string GetChildActionUniqueId(ActionExecutingContext filterContext)
{
    StringBuilder builder = new StringBuilder();
    builder.Append("_MvcChildActionCache_");
    builder.Append(filterContext.ActionDescriptor.UniqueId);
    builder.Append(DescriptorUtil.CreateUniqueId(new object[] { this.VaryByCustom }));
    if (!string.IsNullOrEmpty(this.VaryByCustom))
    {
        string varyByCustomString = filterContext.HttpContext.ApplicationInstance.GetVaryByCustomString(HttpContext.Current, this.VaryByCustom);
        builder.Append(varyByCustomString);
    }
    builder.Append(GetUniqueIdFromActionParameters(filterContext, SplitVaryByParam(this.VaryByParam)));
    using (SHA256 sha = SHA256.Create())
    {
        return Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(builder.ToString())));
    }
}

Таким образом, вы можете совершить следующее безумие:

public ActionResult Invalidate()
{
    OutputCacheAttribute.ChildActionCache = new MemoryCache("NewDefault");
    return View();
}

что, очевидно, сделает недействительными все кешированные дочерние действия, которые могут быть не тем, что вы ищете, но я боюсь, что это единственный способ, кроме, конечно, обратного проектирования генерации ключа :-).

@Microsoft, пожалуйста, умоляю вас о ASP.NET MVC 4.0:

1. ввести возможность кэширования пончиков в дополнение к кэшированию дырок пончиков
2. ввести возможность легко истечь результат действия кэшированного контроллера (что-то более MVCish, чем Response.RemoveOutputCacheItem)
3. ввести возможность легко истечь результат кэшированного дочернего действия
4. если вы сделаете 1., то, очевидно, введите возможность истечения срока действия кэшированной части пончика.

Возможно, вы захотите подойти к этому по-другому. Вы можете создать собственный AuthorizeAttribute — он просто разрешит всем — и добавить переопределение метода OnCacheValidation для включения вашей логики. Если базовый OnCacheValidation возвращает HttpValidationStatus.Valid, проверьте, изменилось ли состояние, и если да, верните HttpValidationStatus.Invalid.

public class PermissionsChangeValidationAttribute : AuthorizeAttribute
{
     public override OnAuthorization( AuthorizationContext filterContext )
     {
        base.OnAuthorization( filterContext );
     }

     public override HttpValidationStatus OnCacheAuthorization( HttpContextBase httpContext )
     {
         var status = base.OnCacheAuthorization( httpContext );
         if (status == HttpValidationStatus.Valid)
         {
            ... check if the permissions have changed somehow
            if (changed)
            {
                status = HttpValidationStatus.Invalid;
            }
         }
         return status;
     }
}

Обратите внимание, что есть способы передать дополнительные данные в процессе проверки кэша, если вам нужно отслеживать предыдущее состояние, но вам придется реплицировать некоторый код в базовом классе и добавить собственный обработчик проверки кэша. Вы можете почерпнуть некоторые идеи о том, как это сделать, из моего сообщения в блоге о создании пользовательского атрибута авторизации: http://farm-fresh-code.blogspot.com/2011/03/revisiting-custom-authorization-in.html