Que es una buena práctica usar un contenedor IoC hoy en día es algo que está más que aceptado… la gente que montó ASP.NET MVC lo tiene muy claro y por eso ha creado un framework, que aunque no usa ningún contenedor IoC por defecto, se puede extender para usar uno… P.ej. si quieres que tus controladores sean creados a través de un contenedor IoC (y deberías querrerlo) solo debes crearte una factoría de controladores e indicar a ASP.NET MVC que use esta factoría en lugar de la que viene por defecto.
El siguiente código muestra una factoría de controladores que usa Unity:
/// <summary>
/// ControllerFactory que utilitza Unity per crear els controladors.
/// </summary>
public class UnityControllerFactory : DefaultControllerFactory
{
IUnityContainer container;
public UnityControllerFactory(IUnityContainer container)
{
this.container = container;
}
protected override IController GetControllerInstance (Type controllerType)
{
if (controllerType == null)
throw new ArgumentNullException("controllerType");
if (!typeof(IController).IsAssignableFrom(controllerType))
throw new ArgumentException(string.Format(
"El tipus {0} NO és un controller.", controllerType.Name),
"controllerType");
return this.container.Resolve(controllerType) as IController;
}
}
Indicar a ASP.NET MVC que use dicha factoría es tan fácil como meter lo siguiente en algún punto del Application_Start del Global.asax:
IUnityContainer container = new UnityContainer();
IControllerFactory factory = new UnityControllerFactory(container);
ControllerBuilder.Current.SetControllerFactory(factory);
Listos! Ahora nuestros controladores serán creados por Unity…
Lamentablemente incluso un framework tan extensible como ASP.NET MVC a veces no es tan extensible como nos gustaría… Una de las capacidades más interesantes de ASP.NET MVC son los llamados filtros. Un filtro es una forma de inyectar código que se ejecuta antes y/o después de que se ejecute el código de una acción de un controlador. El propio framework viene con varios filtros, como p.ej. Authorize que impide ejecutar una acción de un controlador si el usuario no está autenticado. El uso de filtros es uno de los mecanismos más interesantes de ASP.NET MVC y permite la aplicación de técnicas de la programación orientada a aspectos.
Seguro que si pensáis un poco os vienen a la cabeza muchas posibles ideas: P.ej. hacer un logging de todas las acciones, habilitar políticas de caching, gestionar los errores redirigiendo a una o varias páginas de error… Muchas de estas ideas (y más) ya vienen implementadas en el framework, pero lo bueno es que podemos crearnos nuestros propios filtros para crear nuestras propias tareas.
Los filtros se aplican a las acciones mediante atributos, p.ej. en el caso del filtro para autorización, decoraríamos las acciones:
[Authorize(Roles="Admin")]
public ActionResult Create()
{
return View();
}
En este caso la acción sólo se ejecutará si el usuario está autenticado y además tiene el rol “Admin”.
Crear un filtro propio no es especialmente complejo, basta derivar de FilterAttribute y adicionalmente implementar uno o varios de los siguientes interfaces:
- IAuthorizationFilter: Si debemos autorizar el uso o no de la acción en función de determinados parámetros
- IActionFilter: Para ejecutar lógica de negocio antes y después de la propia acción (el caso más común)
- IResultFilter: Para ejecutar lógica de negocio antes y después de la ejecución del resultado de la acción.
- IExcepcionFilter: Para gestionar errores.
Se pueden implementar uno o varios de esos interfaces. La clase FilterAttribute deriva de Attribute por lo que para aplicar nuestro propio filtro, basta con decorar las acciones.
Bueno… a lo que íbamos que me pierdo: si usáis un contenedor IoC para crear vuestros controladores seguramente desearéis usar el mismo contenedor IoC para instanciar vuestros filtros… Desgraciadamente esto no es tan directo como “crear una factoría de filtros” y registrarla, así que requiere un poco de más de trabajo. Os cuento dos técnicas para usar un contenedor IoC (en mi caso Unity) para vuestros filtros propios.
Técnica 1: Tener el contenedor como variable de aplicación
Esta es la más sencilla de todas: en global.asax, guardais el contenedor IoC en alguna variable de aplicación y luego en el filtro la recuperáis (por suerte tenemos acceso al HttpContext). En mi caso estoy implementando un IAuthorizationFilter, y en el código del método OnAuthorization tengo lo siguiente:
public void OnAuthorization(AuthorizationContext filterContext)
{
IUnityContainer container = filterContext.HttpContext.Application["container"] as IUnityContainer;
IGlobalSettings settings = container.Resolve<IGlobalSettings>();
// Código...
}
En este caso IGlobalSettings es el objeto registrado a Unity. Podemos acceder a Unity, porque lo tengo guardado en una variable de aplicación (en global.asax es donde lo guardo), y puedo acceder a las variables de aplicación a través del filterContext, que recibo como parámetro.
Todas las interfaces de los filtros reciben el filterContext excepto IActionFilter que recibe un ControllerContext, pero desde el ControllerContext también se puede acceder a las variables de aplicación.
Técnica 2: Usar un Custom ActionInvoker
Esta técnica consiste en extender el framework de ASP.NET MVC por uno de sus muchos puntos, y nos vamos a crear un custom ActionInvoker. El ActionInvoker es el encargado de “invocar” las acciones de los controladores, y por tanto es donde se crean los filtros asociadas a dichas acciones. Luego podemos indicar a los controladores que se creen que usen nuestro propio ActionInvoker.
En este caso nuestra propoa ActionInvoker lo que debe hacer es inyectar los valores a los filtros. Nunca podremos crear los filtros usando Unity ya que los filtros son atributos, y por tanto son “creados automáticamente” por el CLR. El código de nuestra ActionInvoker puede ser tal y como sigue:
public class UnityActionInvoker : ControllerActionInvoker
{
private IUnityContainer container;
public UnityActionInvoker(IUnityContainer container)
{
this.container = container;
}
protected override FilterInfo GetFilters(ControllerContext controllerContext, ActionDescriptor actionDescriptor)
{
var filters = base.GetFilters(controllerContext, actionDescriptor);
foreach (var filter in filters.ActionFilters)
{
if (!(filter is IController)) container.BuildUp(filter.GetType(), filter);
}
foreach (var filter in filters.AuthorizationFilters)
{
if (!(filter is IController)) container.BuildUp(filter.GetType(), filter);
}
foreach (var filter in filters.ExceptionFilters)
{
if (!(filter is IController)) container.BuildUp(filter.GetType(), filter);
}
foreach (var filter in filters.ResultFilters)
{
if (!(filter is IController)) container.BuildUp(filter.GetType(), filter);
}
return filters;
}
}
El código es bastante simple: el método que nos interesa se llama “GetFilters”. Este método es el encargado de obtener los filtros asociados a la acción de un controlador. Los filtros se devuelven en un objeto FilterInfo, que básicamente son cuatro colecciones para los distintos tipos de filtros que tenemos. Nuestro código se limita a recorrer dichas colecciones y por cada filtro ejecutar el método BuildUp de Unity que inyecta las dependencias. En este caso obviamente no podemos utilizar inyección de dependencias en el constructor (puesto que el objeto ya está creado), pero si podemos utilizar inyección de propiedades.
El código de mi filtro ahora queda tal y como se ve:
[Dependency]
public IGlobalSettings Settings { get; set; }
public void OnAuthorization(AuthorizationContext filterContext)
{
// Código...
}
La propiedad Settings es la que Unity inyectará a mi filtro cuando se llame al método BuildUp.
Los más observadores habréis visto que en mi Custom ActionInvoker, cuando recorro el FilterInfo miro que el filtro no sea de tipo IController: los controladores son filtros de ASP.NET MVC, y además la clase Controller implementa los cuatro interfaces posibles de filtro (por lo que aparecerá UNA vez en cada colección de FilterInfo).
Finalmente, nos queda indicar a cada controlador que use nuestra clase UnityActionInvoker. Para ello basta asignar la propiedad ActionInvoker de cada controlador. Esta propiedad es de la clase Controller (no del interfaz IController). Lo podemos hacer de tres maneras:
- En el constructor de cada controlador (no muy recomendable por tedioso)
- Derivar todos nuestros controladores de una clase base y hacerlo en el constructor de la clase base
- Hacerlo en nuestra factoría de controladores (en el método GetControllerInstance):
protected override IController GetControllerInstance (Type controllerType)
{
// Código anterior...
controller.ActionInvoker = container.Resolve<UnityActionInvoker>();
return controller;
}
Y listos! Ahora sí: nuestros filtros ya pueden usar propiedades inyectadas por Unity! :)
Y ya por curiosidad…
Igual alguno de vosotros se pregunta como era mi filtro: en mi caso estoy desarrollando una aplicación web que es (o será cuando los dioses quieran) un juego. Algunas de las acciones sólo pueden ser ejecutadas cuando el juego está en marcha (con independencia de si el usuario está autenticado o no). Podría poner un if() en cada una de las acciones pero… cuando veais que debeis poner un if() idéntico en muchas acciones, considerad el uso de un filtro.
En mi caso el filtro lo que hace es redirigir a una página de error en caso de que el juego no esté en marcha y la acción requiera que el juego si que lo esté (o viceversa, ciertas acciones de administración sólo se deben poder realizar con el juego parado).
El código del filtro es tal y como sigue:
public class GameStartedAttribute : FilterAttribute, IAuthorizationFilter
{
private readonly bool started;
public GameStartedAttribute()
{
this.started = false;
}
public GameStartedAttribute(bool started)
{
this.started = started;
}
[Dependency]
public IGlobalSettings Settings { get; set; }
public void OnAuthorization(AuthorizationContext filterContext)
{
IUnityContainer container = filterContext.HttpContext.Application["container"] as IUnityContainer;
IGlobalSettings settings = container.Resolve<IGlobalSettings>();
if (settings.GameStarted != this.started)
{
filterContext.Result = new ViewResult()
{
ViewName = settings.GameStarted ? "GameStarted" : "GameNotStarted"
};
}
}
}
En este caso es un IAuthorizationFilter, ya que en cierta manera estamos autorizando peticiones (acciones) no en función del usuario, sinó en función del juego. En el método OnAuthorization se redirige al usuario a las dos páginas de error si el estado del juego no es el pedido, y en caso contrario no se hace nada (y se ejecuta la acción).
La forma de aplicar el filtro es decorando las acciones con el atributo [GameStarted]:
// El juego debe estar en marcha para ejecutar esta acción. Si el juego está
// parado el usuario será redirigido a una página explicativa.
[GameStarted(true)]
public ActionResult Index()
{
return View();
}
Como siempre espero que el post os haya resultado útil para daros cuenta de lo extensible que resulta ser ASP.NET MVC ;-)
Un saludo a todos!!!!!
PD: Esto es un crosspost de mi blog en geeks!!!
No hay comentarios:
Publicar un comentario