ASP.NET Web API: Validando con Global Action Filters

En esta cuarta entrega sobre ASP.NET Web API veremos como aplicar validaciones a nivel global del proyecto. Si observamos la forma en que manejamos los errores del modelo en el método de acción Post(), podemos identificar un patrón común para todas las validaciones:

Validación del modelo

Validación del modelo

Por lo tanto, porque no gestionarlo de manera global,y despreocuparnos de este tema. ASP.NET MVC nos proporciona un mecanismo para esto, y son los Global Action Filters que nos permiten ejecutar lógica antes o después de un método de acción (sobre este tema ya habíamos hablamos en este post).

Momento de definir el filtro de acción global que llamaremos ValidationActionFilter:

Definición del filtro de acción ValidationActionFilter

Definición del filtro de acción ValidationActionFilter

Acto seguido, registrar el filtro de acción en el método Application_Start() del archivo Global.asax:

Registrando el filtro de acción

Registrando el filtro de acción

Finalmente limpiamos el método de acción Post():

Método de acción Post()

Método de acción Post()

Probemos nuevamente el formulario, y las validaciones deberían actuar de la misma forma:

Validaciones del formulario

Validaciones del formulario

Espero que les haya servido y en próximos post vamos a continuar con más características de ASP.NET Web API.

ASP.NET MVC – Gestionando la memoria Cache

Hace un tiempo que estoy leyendo acerca de HTML y algunos de los temas que me llamo la atención fueron sobre la directiva HEAD. Esta directiva corresponde al encabezado de un documento HTML y contiene información que nos ayuda a interpretar y mantener el contenido de su cuerpo – BODY.

<html>
<head>
<title>Title of the document</title>
</head>
<body>
The content of the document……
</body>
</html>

Una de las directivas que componen el encabezado es META. Esta directiva suele tener dos usos: como contenedor de meta-información sobre el documento (generalmente utilizada para indexar dichos documentos con los navegadores), o como contenedor de información adicional relacionada con el protocolo HTTP . Si deseamos utilizar la directiva META para el primer caso, debemos hacer uso del atributo NAME y para el segundo caso el atributo HTTP-EQUIV. Un ejemplo de ambos uso es el siguiente:

<head>
<meta name=”description” content=”Free Web tutorials” />
<meta name=”keywords” content=”HTML,CSS,XML,JavaScript” />
<meta name=”author” content=”Hege Refsnes” />
<meta http-equiv=”content-type” content=”text/html;charset=UTF-8″ />
</head>

La etiqueta HTTP-EQUIV, nos permite tener control sobre los navegadores, y suelen ser utilizadas para: recargas automáticas de página, controlar la cache del navegador, especificar la fecha de espiración del documento o el lenguaje “nativo” del mismo entre otras opciones.

En esta oportunidad, nos vamos a enfocar en la administración de la cache del documento, la cual esta espeficiada por el valor “cache-control“:

<meta http-equiv=”cache-control” content=”no-cache” />

Nota: para los nostálgicos, en Netscape la misma se representaba de la siguiente manera:

<meta http-equiv=”pragma” content=”no-cache/cache” />

Los valores posibles del encabezado cache-control son:

  • public: las caches de los clientes y las cachés compartidas (de servidores proxy) pueden almacenar la respuesta.
  • private: la respuesta sólo se almacena en la memoria caché del cliente y no en memorias caché compartidas (servidor proxy).
  • no-cache: no cache.
  • no-store: se realiza la cache del contenido pero no es archivada.

Veremos más adelante que .NET provee un enumerado de dichos valores.

Otros atributos que podemos especificar en este encabezado son los siguientes:

  • max-age: representa el tiempo de caducidad, especificado en segundos, y se cuenta a partir del momento en que se realiza la petición del recurso, por lo que ofrece mayor flexibilidad.
  • s-maxage: similar a max-age, pero sólo se aplica a cachés proxy.
  • must-revalidate: comunica a las cachés que deben seguir estrictamente todas nuestras reglas sobre la caducidad de los recursos. El protocolo HTTP da a las cachés cierta libertad a este respecto, la cual se puede restringir con esta directriz.
  • proxy-revalidate: similar a must-revalidate, pero sólo se aplica a cachés proxy.

Ahora bien, teniendo en cuenta todo esto, podríamos crear un filtro de acción en ASP.NET MVC para establecer que nuestras páginas sean almacenen en la memoria cache. Para esto vamos a crear la clase CacheAttribut que deberá heredar de la clase ActionFilterAttribute.

Una de las propiedades de dicha clase será la duración de la cache (representada en segundos) y la segunda el valor del encabezado HTTP Cache-Control representado por enumerado HttpCacheability:

Valores posibles del encabezado HTTP Cache-Control

Valores posibles del enumerado HttpCacheability

Para poder indicarle al navegador que queremos almacenar en la chace la página que estamos sirviendo, necesitamos interceptar la ejecución de la misma y agregar en el encabezado directivas META con el atributo http-equiv correspondiente al manejo de la cache. Para esto vamos a sobre-escribir el método OnActionExecuted en el nuevo filtro de acción:

Como vemos, el parametro que recibe este método es del tipo ActionExecutedContext y representa el contexto en el cual se esta ejecutando una acción. Una de las propiedades es del tipo HttpCachePolicyBase la cual nos permitirá establecer las políticas de caché de la página web.

Veamos una definición mas completa que no brinda MSDN sobre el namespace System.Web.HttpCachePolicyBase:

Actúa como clase base para las clases que contienen métodos para establoecer los encabezados HTTP específicos de la memoria caché y para controlar la memoria caché de resultados de las páginas ASP.NET.

Ok, ahora ya tenemos listo nuestro ActionFilter, vamos a ponerlo a prueba. 🙂

Lo primero será ejecutar nuestra aplicación sin el uso de cache, para eso definimos una vista llamada Index de la forma habitual, y veamos la respuesta del servidor:

Respuesta del servidor

Respuesta del servidor

Sin especificar nada en el proyecto, ASP.NET MVC retorna páginas con el tipo de cache Private sin ningún otro tipo de especificación.

Ahora vamos a agregarle el atributo Cache, especificando que será del tipo Public con una duración de 60 segundos:

Ejecutemos y veamos la respuesta:

Respuesta del servidor

Respuesta del servidor

Como veran, la memoria cache esta especificada como Public, con una duración (max-age) de 60 segundos. También tenemos con información del encabezado la fecha y hora en que expira la misma.

Para terminar, quiero decirles que ASP.NET MVC ya nos provee de un filtro de acción que nos permite establecer cuestiones propias de la cache: el action filter OutputCache. Veamos un ejemplo rápido de su uso, en este caso para especificar que no queremos utilizar ningun tipo de cache en la vista:


La respuesta del servidor es la siguiente:

Respuesta del servidor

Respuesta del servidor

Vean que la fecha de espiración de la cache es la misma fecha en la que es devuelto el documento, por lo que al servir nuevamente la página la misma se obtendrá directamente del servidor y no de la cache del servidor proxy o del cliente. Utilizando esta librería podemos realizar configuraciones del manejo de la cache de manera global al sitio, o crear distintos perfiles de cache especificandolos en el archivo web.config.

Recomiendo que lean el siguiente tutorial del sitio oficial de ASP.NET MVC acerca de este tema.

Quienes quieran descargar el proyecto pueden hacerlo desde acá: MyMvcApplication – ManejoMemoriaCache.rar.

Espero que les sea de utilidad!