2008-12-22 25 views
81

Me gustaría almacenar en caché la mayoría de las acciones pesadas de la base de datos en mi sitio asp.net-mvc. En mi investigación he encontradoAlmacenamiento en caché en asp.net-mvc

  • donut caching en el blog de Phil
  • Caching/compressing filtros en el blog de Kazi
  • de podcast de Scott Hansleman acerca de cómo se almacenan en caché las cosas en SO.

Pero no creo que lo tenga todavía.
Quiero poder guardar en caché mi solicitud POST dependiendo de varios pares. Estos pares están en un objeto. Así que me gustaría para almacenar en caché el resultado de la petición siguiente:

public ActionResult AdvancedSearch(SearchBag searchBag) 

Dónde searchBag es un objeto que tiene (un montón) de los parámetros de búsqueda opcionales. Mis vistas en sí mismas son ligeras (como deberían ser), pero el acceso a los datos puede consumir bastante tiempo, dependiendo de qué campos se llenen en la bolsa de búsqueda.

Tengo la sensación de que debería almacenar en caché mi capa de datos, en lugar de mis acciones.
¿Cómo se supone que debo usar VaryByParam en el atributo OutputCache?

+2

¿Has probado con VaryByParam = "searchBag.property"? –

+0

no, no tengo. Intentare lo que dices. Pero, ¿qué hay de enumerar varios parámetros? –

+2

VaryByParam = "firstParam; secondParam; thirdParam" –

Respuesta

73

También me gusta almacenar en caché el modelo o la capa de datos. Esto aísla todo lo relacionado con la recuperación de datos del controlador/presentación. Puede acceder a la memoria caché de ASP.NET desde System.Web.HttpContext.Current.Cache o utilizar el Bloque de aplicación de almacenamiento en caché desde la Biblioteca de empresa. Cree su clave para los datos almacenados en caché a partir de los parámetros de la consulta. Asegúrese de invalidar la caché cuando actualice los datos.

+1

Debo leer en la biblioteca de la empresa, creo. Dado que la mayor parte del retraso recae en la capa de datos, supongo que será la mejor solución al final. Actualmente es una base de datos de solo lectura, por lo que elimina el problema del objeto obsoleto :) –

+17

El bloque de la aplicación de almacenamiento en caché parece un completo desastre de excesos. Descubrí que en casi todos los casos HttpRuntime.Cache es más que adecuado. –

+3

¿Por qué overkill? Ahora estoy mucho más avanzado y he descubierto que el sistema de caché de EL es realmente fácil de usar. Haga referencia a la biblioteca correcta, agregue las líneas de configuración correctas y puede iniciar el almacenamiento en caché y la recuperación de objetos con una línea de código cada uno. –

65

O puede ser independiente de la HttpContext.Current y acceso a la caché de HttpRuntime.Cache :)

+0

Lo cual también significa que aún podrá acceder al 'caché' cuando el código se esté ejecutando en un hilo de fondo (es decir, async/await goodness). –

11

A menudo, OutPutCaching puede ser el más rápido y eficiente, pero sólo cuando se adapte a sus necesidades. ¡No tiene sentido tener una rápida eficiencia si está mal! ;)

En este caso, parece que el almacenamiento en caché de la capa de datos es correcto porque tiene necesidades complejas de almacenamiento en caché. A veces, puede combinar los dos si el conjunto de parámetros que controla qué salida se almacena en caché es simple.

0

puede utilizar el almacenamiento en caché de salida algo como esto

[OutputCache(Duration = 10, VaryByParam = "empID")] 
     public ActionResult GetEmployeeDetail(int empID) 
     { 
      Employee e = new Employee(); 
      return Content(e.getEmployeeDetails(empID)); 
     } 

o puede utilizar los perfiles de caché pusieron en web.config

<caching> 
<outputCacheSettings> 
    <outputCacheProfiles> 
     <add name="Admin" 

     duration="86420" varyByParam="none"/> 
    </outputCacheProfiles> 
</outputCacheSettings> 
</caching> 

and use this tag 
[OutputCache(CacheProfile="Admin")] 
Cuestiones relacionadas