Burbujas en .NET : IoC

EF4 Code First, MVC2 y Unity para atarlo todo un poco…

Eduard Tomàs i Avellana — Fri, 24 Sep 2010 10:57:00 GMT

Buenas! No soy ni mucho menos un experto en EF (es más, me acabo de poner), como pueda serlo p.ej. Unai, pero desde que Scott Guthrie publicó un post sobre EF Code First he empezado a mirar algunas cosillas.

Resumiendo rápidamente EF Code First nos permite desarrollar nuestra capa de acceso a datos codificando primero las clases, clases que son POCO. Eso nos permite conseguir lo que se conoce como persistance ignorance (o que las clases que nos representan los datos sean agnósticas sobre cualquier tecnología de acceso a datos).

Que quede claro que Code First no es la única manera de usar objetos POCO en EF: Unai y Alberto hablan del tema aquí y aquí. Y dad por seguro que ellos conocen EF mucho más que yo :)

Lo que os quiero comentar es como se puede montar EF Code First en una aplicación MVC2 para poder usar el patrón Repository y Unit Of Work, de forma que los controladores no deban saber nada del mecanismo subyacente de acceso a datos (es decir, los controladores ignoran completamente que están usando EF).

1. Rápida, rapidísima introducción a EF Code First

Usar EF Code First es muy sencillo. En el post de Scott Guthrie está todo explicado paso a paso, pero resumiendo podríamos decir que me puedo crear una clase tal que:

public class Persona
{
   public int PersonaId {get; set;}
   public string Nombre {get; set;}
}

Esta clase nos permitiría acceder a datos almacenados en una tabla con los campos PersonaId y Nombre (EF Code First es capaz de crear la BBDD a partir del modelo de objetos). Para acceder a la bbdd creamos un objeto derivado de DbContext:

public class MyDatabase : DbContext
{
   public DbSet<Persona> Personas {get; set;}
}

Y a partir de aquí instanciamos un objeto MyDatabase y lanzamos consultas linq contra la propiedad Personas… :)

2. Patrón repositorio y Unit of work

Esos patrones están explicados por activa y por pasiva en muchos sitios. P.ej. aquí está el patrón repositorio y aquí el Unit of Work (UoW). Básicamente entendemos que el repositorio es una colección de objetos en memoria y que el patrón UoW sincroniza todos los cambios hechos en memoria hacia la base de datos.

Supongamos estos dos interfaces para definir ambos patrones:

public interface IRepository<TEntity> where TEntity : class
{
    IQueryable<TEntity> AsQueryable();    
    IEnumerable<TEntity> GetAll();
    IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> where);
}

public interface IUnitOfWork
{
    void Commit();
}

Mi repositorio es de sólo lectura (no hay métodos Add ni Remove ni nada, pero todo es añadirlos) y el Unit of Work lo único que tiene es el método Commit() para sincronizar los cambios hechos en los repositorios y mandarlos todos a la base de datos.

EF Code First, implementa de per se el patrón Unit Of Work (a través de DbContext) y también el patrón repositorio a través de DbSet<>, pero recordad que yo quiero “agnostizarme” al respecto de EF, por eso creo las interfaces y ahora debo crear implementaciones de ellas para EF:

public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
{
    private IDbSet<TEntity> _dbSet;

    public Repository(IDbContext objectContext)
    {
        _dbSet = objectContext.Set<TEntity>();
    }
    public IQueryable<TEntity> AsQueryable()
    {
        return _dbSet;
    }
    public IEnumerable<TEntity> GetAll()
    {
        return _dbSet.ToList();
    }
    public IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> where)
    {
        return _dbSet.Where(where);
    }
}

public class UnitOfWork : IUnitOfWork, IDisposable
{
    private readonly IDbContext _objectContext;
    
    public UnitOfWork(IDbContext objectContext)
    {
        _objectContext = objectContext;
    }

    public void Dispose()
    {
        if (_objectContext != null)
        {
            _objectContext.Dispose();
        }
        GC.SuppressFinalize(this);
    }

    public void Commit()
    {
        _objectContext.SaveChanges();
    }
}

La única “complicación” es en la implementación de UnitOfWork, que en el constructor uso un objeto de tipo IDbContext, pero esta interfaz no existe en EF: me la he inventado yo, para poder realizar DI luego cuando use Unity. La interfaz IDbContext es muy simple:

public interface IDbContext : IDisposable
{
    IDbSet<T> Set<T>() where T : class;
    int SaveChanges();
}

Me permite obtener un IDbSet de entidades de tipo T y el método SaveChanges para persistir los cambios realizados en este contexto hacia la BBDD.

3. Uso de todo esto…

Para usar directamente un repositorio me basta con instanciarlo, pasándole como parámetro el IDbContext. Pero recordad que la clase DbContext de EF Code First no implementa IDbContext (que me lo he inventado yo), así que uso el patrón Adapter para traducir los objetos DbContext a IDbContext:

public class DbContextAdapter : IDbContext
{
    private readonly DbContext _context;
    public DbContextAdapter(DbContext context)
    {
        _context = context;
    }
    public void Dispose()
    {
        _context.Dispose();
    }
    public IDbSet<T> Set<T>() where T : class
    {
        return _context.Set<T>();
    }
    public int SaveChanges()
    {
        return _context.SaveChanges();
    }
}

Ahora sí que ya puedo crear un repositorio:

IDbContext ctx = new DbContextAdapter(MyDatabase);  // MyDatabase deriva de DbContext
var rep = new Repository<Persona>(ctx);
var personas = rep.FindAll();

Para usar el Unit of Work vinculado a un contexto haríamos lo mismo.

4. Añadiendo IoC a todo esto…

Ahora que ya vemos como podemos usar nuestro repositorio, vamos a ver como Unity nos ayuda a tener IoC y independizarnos realmente de EF.

Primero podríamos registrar las implementaciones concretas de IRepository y IUnitOfWork:

// Container es el IUnityContainer
Container.RegisterType(typeof(IRepository<>), typeof(Repository<>));
Container.RegisterType<IUnitOfWork, UnitOfWork>();

Ahora debemos mapear IDbContext a DbContextAdapter (porque para instanciar tanto IRepository como IUnitOfWork les debemos pasar un IDbContext. Podríamos usar lo siguiente:

Container.RegisterType<IDbContext, DbContextAdapter>();

Este RegisterType está bien, pero el problema nos viene cuando vemos que el constructor de DbContextAdapter tiene un objeto DbContext. Eso significaría que Unity nos crearía un objeto de la clase DbContext y no de la clase derivada MyDatabase, para instanciar los objetos DbContextAdapter. Nota: Una solución sería que la clase DbContextAdapter tuviese en su constructor un objeto que no fuera DbContext sinó MyDatabase pero eso entonces limita la reutilización de todo lo que estamos haciendo!

Por suerte no estamos perdidos! Unity incorpora un mecanismo mediante el cual le podemos decir como crear un objeto de una determinada clase. En mi post sobre Unity 2.0, hablé de las Injection Factories. La idea es decirle a Unity que cuando necesite un objeto de la clase indicada, en lugar de crearlo tal cual use una factoría nuestra.

Es decir podemos hacer una factoría para crear DbContext que en lugar de un DbContext devuelva un MyDatabase, y Unity usará dicha factoría cada vez que deba crear un DbContext:

Container.RegisterType<DbContext>(new InjectionFactory(x => new MyDatabase()));

Listos! Con esto cuando Unity deba pasar a DbContextAdapter un objeto DbContext (como indica el constructor) creará realmente un objeto MyDatabase.

Ahora si que ya puedo hacer:

var rep = Container.Resolve<IRepository<Persona>>();

5. Y finalmente… MVC2

Para integrar esto dentro de MVC2 es muy sencillo: como siempre que queramos inyectar IoC en los controladores lo que debemos tocar es… la factoría de controladores:

public class UnityControllerFactory : DefaultControllerFactory
{
    private readonly IUnityContainer _sl;

    public UnityControllerFactory(IUnityContainer sl) 
    {
        _sl = sl;
    }

    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
    {
        IController controller = _sl.Resolve(controllerType);
        return controller;
    }
}

Y como siempre establecerla en el Global.asax:

UnityControllerFactory slcf = new UnityControllerFactory(container);
ControllerBuilder.Current.SetControllerFactory(slcf);

Y listos! Ahora si que hemos llegado al punto final. Por fin podemos declarar un controlador tal que:

public class PersonasController : Controller
{
    private IRepository<Persona> _rep;
 
    public HandController(IRepository<Persona> rep)
    {
        _rep = rep;
    }
}

Y empezar a trabajar usando el repositorio! :)

Fijaos que en este punto (el controlador) no tenemos nada que nos ate a EF: el repositorio es una interfaz y las clases que usa el repositorio son objetos POCO.

6. Y para terminar (pero NO lo menos importante)…

Cuando trabajamos con aplicaciones web, es recomendable que los contextos de base de datos tengan una duración (lifetime) de request (se les llama objetos per-request): es decir si durante una misma petición se necesitan dos repostorios, estos dos repositorios deben de compartir del contexto de base de datos. Con lo que tenemos ahora no sucede esto, ya que cada vez que Unity deba crear un Repository<> creará su DbContextAdapter asociado que a su vez creará un DbContext (MyDatabase) nuevo. Ese comportamiento no es el desado.

Por suerte Unity tiene un mecanismo muy bueno para poder establecer cada cuando debe el contenedor crear un objeto de un tipo determinado: los lifetime managers. Una solución es crearse un HttpRequestLifetimeManager, de forma que los objetos sólo persistirán durante la misma petición y usar este lifetime manager cuando hagamos el RegisterType de DbContext.

En http://unity.codeplex.com/Thread/View.aspx?ThreadId=38588 tenéis una implementación de un HttpRequestLifetimeManager, junto con una interesante aportación sobre el uso (en su lugar) de contenedores hijos que mueran a cada request, que tengan los objetos registrados como singletons y eliminar el contenedor hijo (con Dispose()) al final de cada request. Esto tiene la ventaja de que se llamaría a Dispose() de los objetos contenidos (en esta segunda aproximación es el contendor hijo el que tiene un ciclo de vida per-request).

7. Referencias

Los siguientes posts contienen más información al respecto:

Entity Framework POCO (EF4): Generic Repository and Unit of Work Prototype. Este es el post que me ha servido de inspiración y de ayuda. Tiene una continuación (Unity Extension for Entity Framework POCO Configuration, Repository and Unit of Work) donde comenta el uso de Unity. Estos dos posts son de lectura imprescindible, aunque por un lado haya tenido que modificar algunas cosillas para que funcione con la CTP4 de EF Code first y por otro en el tercer post utilize una StaticFactoryExtension en lugar de una Injection Factory (supongo que usa Unity 1.2 que no soporta Injection Factories). Este tercer post utiliza una aproximación genial que es el uso de una extensión de Unity para configurar todos los mappings para los objetos de EF. Repito: lectura imprescindible.
Los posts de Scott Guthrie sobre EF Code First:

Un saludo!!! :)

Novedades de Unity 2.0

Eduard Tomàs i Avellana — Wed, 02 Jun 2010 13:02:56 GMT

Unity, el contenedor IoC de Microsoft, hace algunas semanas que tiene nueva versión: la 2.0. Y viene con algunas novedades interesantes respecto a la versión anterior, que os comento brevemente :)

Por fin… un único assembly!

Vale que Unity era poco más que un wrapper sobre ObjectBuilder2 pero tampoco era necesario que nos lo recordaran continuamente… ahora ya no tendremos que añadir la referencia a ObjectBuilder2 además de la referencia a Unity cada vez… Ahora existe un solo assembly: Microsoft.Practices.Unity.dll. ¿Un detalle sin apenas importancia? Pues probablemente :)

Resoluciones deferidas

Esta funcionalidad nos permite resolver tipos con Unity sin tener una dependencia contra Unity. P.ej. imagina que tenemos Unity configurado de la siguiente manera:

IUnityContainer uc = new UnityContainer();
uc.RegisterType<IA, A>();

Y tenemos un método que necesita construir un objeto IA a través de Unity… Antes debíamos pasarle el contenedor Unity:

static void OldFoo(IUnityContainer ctr)
{
    // ... Código antes de resolver IA ...
    IA a = ctr.Resolve<IA>();
}

Ahora, con Unity 2.0 podemos obtener un resolvedor (perdonad por la palabreja) que no es nada más que un delegate que cuando sea invocado llamará a Resolve de Unity. Esto nos permite que la función OldFoo no tenga dependencia alguna contra Unity:

static void NewFoo(Func<IA> resolver)
{
    // ... Código antes de resolver IA ...
    IA a = resolver();
}

Y la llamada a NewFoo quedaría de la forma:

var resolver = uc.Resolve<Func<IA>>();
NewFoo(resolver);

De esta manera el método NewFoo no necesita para nada el contenedor Unity :)

Paso de parámetros en Resolve

Esto permite pasar parámetros a un objeto cuando se llama a su método Resolve.

Supon que tenemos lo siguiente:

interface IB { }

class B : IB
{
    public B(int value) { }
}

Y tenemos un mapping declarado en Unity:

IUnityContainer uc = new UnityContainer();
uc.RegisterType<IB, B>();

Como es de esperar la siguiente llamada falla:

IB b = uc.Resolve<IB>();
// Exception is: InvalidOperationException - The type Int32 cannot be constructed.

Unity se queja, porque cuando va al constructor de la clase B se encuentra que le debe pasar un parámetro de tipo Int32 (int). Pero como no tiene ningún mapeo de int, se queja.

Para solucionar este caso podemos usar los ResolverOverride. P.ej. para pasarle el valor 3 al parámetro “value” basta con usar:

IB b = uc.Resolve<IB>(new ParameterOverride("value", 3));

Pero no solo nos sirven para especificar valores de parámetros cuyos tipos no estén registrados en el contenedor, también podemos indicarle valor a un parámetro incluso en el caso que Unity pudiese proveer un valor para el parámetro:

interface IA { }
class A : IA { }
interface IB { IA A { get; } }
class B : IB
{
    public IA A { get; private set; }
    public B(IA a)
    {
        A = a;
    }
}

class Program
{
    static void Main(string[] args)
    {
        IUnityContainer uc = new UnityContainer();
        uc.RegisterType<IA, A>(new ContainerControlledLifetimeManager());
        uc.RegisterType<IB, B>();
        IA a1 = uc.Resolve<IA>();
        IA a2 = uc.Resolve<IA>();
        IB b = uc.Resolve<IB>();
        IB b2 = uc.Resolve<IB>(new ParameterOverride("a", new A()));
    }
}

Dado el siguiente código tenemos que:

a1 == a2 es true puesto que IA está registrado como singleton, por lo que todas las llamadas a Resolve<IA> devuelven el mismo valor
a1 == b.A es true por la misma razón de antes: Cuando Unity debe proporcionar un valor IA al constructor de la clase B, utiliza el método Resolve por lo que devuelve el singleton.
a1 == b2.A es false porque aquí aunque Unity puede proporcionar un valor para el parámetro, el valor especificado en el ParameterOverride tiene preferencia.

Por fin!!! Podemos saber que hay registrado en el contenedor

Se han añadido métodos para saber todos los registros de mapeos del contenedor y para saber si un mapeo en concreto existe:

IUnityContainer uc = new UnityContainer();
uc.RegisterType<IA, A>(new ContainerControlledLifetimeManager());
uc.RegisterType<IB, B>();
bool isTrue = uc.IsRegistered<IA>();
bool isFalse = uc.IsRegistered<IC>();
int numRegs = uc.Registrations.Count();

Por cierto, que dado el siguiente código… cuanto vale numRegs?

Sí habeis dicho 2, habéis fallado… recordad que Unity se registra a si mismo, por lo que realmente numRegs vale 3 (el propio registro de Unity, el de IA y el de IB).

InjectionFactory

InjectionFactory es un mecanismo que permite indicarle a Unity un método (una Func<IUnityContainer, object>, usualmente una lambda expresion) a usar cada vez que deba resolver un objeto especificado. Permite que Unity use factorías nuestras.

Imagina que tenemos una factoría para crear objetos IA:

interface IFactory
{
    IA GetNewInstance();
}
class Factory : IFactory
{
    public IA GetNewInstance()
    {
        // Hace lo que tenga que hacer nuestra factoria... 
        return new A();
    }
}

Y ahora deseamos usar Unity para la creación de objetos IA. Pues podemos realizar el siguiente Register:

IUnityContainer uc = new UnityContainer();
uc.RegisterType<IFactory, Factory>(new ContainerControlledLifetimeManager());
uc.RegisterType<IA>(new InjectionFactory
    (x => x.Resolve<IFactory>().GetNewInstance()));

En la última línea le estamos indicando a Unity que cada vez que alguien haga un Resolve<IA> ejecute el delegate que le indicamos (en este caso que obtenga una IFactory y llame al método GetNewInstance).

Esto si lo combinamos con lo de las resoluciones diferidas es realmente interesante.

Y estas serían las novedades, a mi juicio, más interesantes de Unity 2 (que no son todas… si las queréis saber todas, las tenéis aquí!).

Objetos que notifican sus cambios de propiedades (2/3): Publish and subscribe

Eduard Tomàs i Avellana — Thu, 14 Jan 2010 09:04:00 GMT

Nota: Este post es el segundo post de la serie Objetos que notifican sus cambios de propiedades.

En el post anterior vimos como configurar Unity para que no tener que añadir código adicional para implementar la interfaz INotifyPropertyChanged. En este post quiero hablaros de un patrón que se utiliza mucho cuando hablamos de aplicaciones complejas: el patrón del publicador – suscriptor. En este patrón tenemos básicamente dos conceptos:

El publicador: Cuando un objeto quiere notificar algo al respecto de su estado, se limita a publicar un mensaje con la información deseada.
El suscriptor: Los subscriptores reciben todos aquellos mensajes a los que están suscritos, con independencia de quien los haya publicado.

Este patrón se diferencia del modelo de eventos estándard de .NET, en que para realizar una suscripción a un tipo de mensaje no es necesario tener referencia alguna a quien pueda publicar este mensaje. En el sistema de eventos no és así: si quiero recibir información sobre el click de un botón, debo tener una referencia a este botón, para poder registrar la función gestora del evento:

button1.Click += new EventHandler(button1_Click);

Este modelo de eventos directos tiene sus limitaciones y da en Winforms bastantes quebraderos de cabeza (especialmente cuando tenemos un formulario con un usercontrol formado por varios usercontrols que a su vez están formados por más usercontrols y queremos propagar un evento del usercontrol más interno al formulario). Es cierto que WPF introduce dos mejoras interesantes como los routed events (que ayudan precisamente a solventar este problema de usercontrols anidados) y los commands, pero ninguno de ambos mecanismos ofrece la misma flexibilidad que el modelo de publicación – suscripción.

Créeme: si desarrollas una aplicación compleja, ya sea en winforms o en WPF, te beneficiará mucho el uso de un modelo de publicación – suscripción (no en vano tanto CAB+SCSF como PRISM incorporan uno).

Vamos a ver como podemos implementarnos uno que, aunque sencillito, sea lo suficientemente funcional…

1. El notificador de mensajes

Lo primero que debemos crear es el notificador de mensajes, es decir el objeto que usamos para publicar un mensaje y el que usamos también para informar a que tipo de mensajes queremos suscribirnos.

El notificador de mensajes va a tener esta interfaz:

public interface ICommandNotifier
{
    /// <summary>
    /// Devuelve la lista de los commands actuales. Los commands se
    /// añaden automáticamente cuando se realiza un publish de cualquier
    /// tipo nuevo.
    /// </summary>
    IEnumerable<Type> Commands { get; }
    /// <summary>
    /// Añade una suscripción al tipo de command TPayload
    /// </summary>
    /// <typeparam name="TPayload">Tipo de command al que nos suscribimos</typeparam>
    /// <param name="func">Acción a ejecutar cuando se publique el command</param>
    /// <param name="filterFunc">Método que se evalúa sobre el payload para determinar
    /// si el command se pasa o no al suscriptor.</param>
    /// <returns>Token de suscripción</returns>
    SubscriptionToken Subscribe<TPayload>(Action<TPayload> func, Func<TPayload, bool> filterFunc);

    /// <summary>
    /// Publica un command. El tipo de command es el tipo de la clase del payload.
    /// </summary>
    /// <param name="payload">Payload (datos) del commanad</param>
    void Publish(object payload);

Básicamente sólo tiene un método para suscribirse a un determinado tipo de mensajes y otro método para publicarlos. Una implementación más compleja nos permitiría también eliminar suscripciones (es decir cuando ya no me interesa seguir recibiendo notificaciones de determinados commands)… pero eso lo dejamos como ejercicio :)

La implementación tampoco es excesivamente compleja (no pongo el código aquí, ya que lo tenéis en el zip que adjunto al final del post). Básicamente lo que hace es:

Mantiene una lista de todos los tipos de mensajes que se hayan lanzado. Lo que determina si un mensaje es de un tipo u otro es su clase (en la implementación una lista de objetos CommandInfo).
Por cada mensaje de esa lista mantiene una lista con todos los suscriptores (en la implementación objetos de la clase AllTimeSubscriber).
Por cada suscriptor de cada mensaje mantiene básicamente dos delegates:
1. El delegate que sirve para decidir si se envía este mensaje a este suscriptor (parámetro filterFunc del método Subscribe)
2. El delegate que debe invocarse en el suscriptor (parámetro func del método Subscribe).

Sólo un apunte: el notificador de mensajes vamos a registrarlo en Unity como un singleton, eso significa que existirá sólo uno y que estará vivo durante toda la ejecución del programa. Por lo tanto, si guardamos directamente los delegates en el notificador de mensajes, impedirá al garbage collector actuar sobre los suscriptores (recordad que un delegate mantiene una referencia a un objeto en concreto y a un método). Para solucionar esto me he creado una clase, que he llamado WeakDelegate, que tiene la misma información que un delegate, pero usa una WeakReference para apuntar al objeto (el suscriptor) y de esta manera permitir actuar al garbage collector. Recordad: siempre que guardeis referencias en un singleton considerad el uso de WeakReference!

2. Cambiar la implementación de nuestro handler

Una vez tenemos un notificador de mensajes, sólo debemos cambiar la implementación de nuestro ICallHandler (clase AutoPropertyChangedHandler) de Unity, para usar dicho notificador. Para ello en el método Invoke en lugar de llamar al método RaiseEvent (para lanzar el evento PropertyChanged) como hacíamos en el post anterior, vamos a usar el notificador para publicar un mensaje de tipo PropertyChangedCommand:

// Si el setter no produce excepción, publicamos un command de tipo PropertyChangedCommand
if (raiseEvt && msg.Exception == null)
{
    cmdNotifier.Publish(new PropertyChangedCommand(propName, input.Target));
}

La clase PropertyChangedCommand es una clase que nos hemos creado nosotros que no hace nada más que guardar el nombre de la propiedad que ha cambiado y el objeto sobre el cual ha cambiado la propiedad.

Como recibe la clase AutoPropertyChangedHandler el notificador de mensajes? Pues se le pasa en el constructor:

public AutoPropertyChangedHandler(ICommandNotifier cmdNotifier)
{
    this.cmdNotifier = cmdNotifier;
}

Ahora sólo debemos modificar la clase AutoPropertyChangedAttribute para que cuando cree el objeto AutoPropertyChangedHandler le pase el notificador de mensajes. La forma más fácil es aprovechar que en AutoPropertyChangedAttribute tenemos acceso a Unity, para devolver el objeto AutoPropertyChangedHandler usando Resolve y que de esa manera Unity inyecte el notificador de mensajes:

public override ICallHandler CreateHandler(IUnityContainer container)
{
    return container.Resolve<AutoPropertyChangedHandler>();
}

3. El suscriptor

Finalmente nos queda crear el suscriptor. Los suscriptores son clases normales que usan el notificador de mensajes para suscribirse a tipos de mensajes. P.ej. el siguiente suscriptor se suscribe a los mensajes cuyo tipo sea PropertyChangedCommand:

public Suscriptor(ICommandNotifier cmdNotif)
{
    cmdNotif.Subscribe<PropertyChangedCommand>(this.DoPropertyChangedCommand, this.CanDoPropertyChangedCommand);
}

private void DoPropertyChangedCommand(PropertyChangedCommand payload)
{
    Console.WriteLine("Propiedad {0} modificada", payload.PropertyName);
}

private bool CanDoPropertyChangedCommand(PropertyChangedCommand payload)
{
    bool retVal = !payload.PropertyName.Equals("Name");
    Console.WriteLine("CanDoPropertyChanged con prop {0} devuelve {1}", payload.PropertyName, retVal);
    return retVal;
}

Fíajos en la función CanDoPropertyChangedCommand: esta función se evalúa cada vez que alguien publica un command y sólo en el caso que devuelva true se ejecutará la función DoPropertyChangedCommand que es la que “procesa” el mensaje. En este caso, este suscriptor está interesado en recibir todos los cambios de calquier propiedad excepto “Name”.

Finalmente sólo nos queda crear un suscriptor y probar el código. En el método Main() tengo:

container.RegisterType<ICommandNotifier, CommandNotifier>(new ContainerControlledLifetimeManager());
A2 a2 = container.Resolve<A2>();
Suscriptor subs = container.Resolve<Suscriptor>();
a2.Name = "edu";
a2.Edad = 10;
// Registramos el notificador como singleton
container.RegisterType<ICommandNotifier, CommandNotifier>(new ContainerControlledLifetimeManager());
// Creamos un A2...
A2 a2 = container.Resolve<A2>();
// ... y un suscriptor
Suscriptor subs = container.Resolve<Suscriptor>();
a2.Name = "edu";
a2.Edad = 10;

Y listos! Sí lo ejecutais veréis que la salida es:

CanDoPropertyChanged con prop Name devuelve False
CanDoPropertyChanged con prop Edad devuelve True
Propiedad Edad modificada

Ya tenemos implementado nuestro propio publicador-suscriptor!

Os dejo un zip con todo el código (en skydrive).

Un saludo!

Objetos que notifican sus cambios de propiedades (1/3): La intercepción

Eduard Tomàs i Avellana — Wed, 13 Jan 2010 12:35:00 GMT

Nota: Este post es el primer post de la serie Objetos que notifican sus cambios de propiedades.

En este post vamos a ver como configurar la intercepción de Unity, para poder inyectar nuestro código cada vez que se modifiquen las propiedades de un objeto.

Los que desarrolléis en WPF sabréis que existe una interfaz llamada INotifyPropertyChanged, que se puede implementar para notificar a la interfaz de usuario de que las propiedades de un objeto (generalmente ligado a la interfaz) han modificado, y que por lo tanto la interfaz debe actualizar sus datos.

Esta interfaz define un solo evento, llamado PropertyChanged que debe lanzarse para informar del cambio de propiedad. Es responsabilidad de cada clase lanzar el evento cuando sea oportuno:

public class A : INotifyPropertyChanged
{
    private string _name;

    // Evento definido por la interfaz
    public event PropertyChangedEventHandler PropertyChanged;

    // Lanza el evento "PropertyChanged"
    private void NotifyPropertyChanged(string info)
    {
        var handler = this.PropertyChanged;
        if (handler != null)
        {
            handler(this, new PropertyChangedEventArgs(info));
        }
    }
    // Propiedad que informa de sus cambios
    public string Name
    {
        get { return _name; }
        set
        {
            if (_name != value)
            {
                _name = value;
                NotifyPropertyChanged("Name"); 
            }
        }
    }
}

Este código es pesado de realizar en clases con muchas propiedades y es fácil cometer errores… además no podemos utilizar las auto-propiedades. Vamos a ver como con el sistema de intercepción de Unity podemos hacer que este evento se lance de forma automática.

1. Configurando el sistema de intercepción de Unity

Para usar el sistema de intercepción de Unity, debéis añadir los assemblies Microsoft.Practices.ObjectBuilder2, Microsoft.Practices.Unity y Microsoft.Practices.Unity.Interception a vuestro proyecto (los tres assemblies forman parte de Unity).

El primer paso es crear una clase que implemente la interfaz ICallHandler, esta clase es la encargada de proporcionarnos un punto dónde inyectar el código:

class AutoPropertyChangedHandler : ICallHandler
{
    public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
    {
        // Aquí podremos inyectar nuestro código
        IMethodReturn msg = getNext()(input, getNext);
        return msg;
    }
    public int Order { get; set; }
}

El siguiente paso es crear un atributo que permita indicar a Unity que ICallHandler debe usar cuando se opere con objetos de la clase. Esta clase debe derivar de HandlerAttribute y debe redefinir el método CreateHandler para devolver una instancia del ICallHandler a utilizar:

class AutoPropertyChangedAttribute : HandlerAttribute
{
    public override ICallHandler CreateHandler(IUnityContainer container)
    {
        return new AutoPropertyChangedHandler();
    }
}

El código es trivial, eh?? Simplemente devuelve un AutoPropertyChangeHandler, de esa manera Unity usará este AutoPropertyChangeHandler para todas las clases que estén decoradas con el atributo AutoPropertyChangedAttribute. De esta manera es como le indicamos a Unity qué ICallHandler debe usar por cada tipo de clase.

Finalmente queda configurar el propio contenedor. Para ello debemos debemos añadir la extensión de intercepción a Unity y indicarle que interceptor queremos utilizar para cada clase:

IUnityContainer container = new UnityContainer();
container.AddNewExtension<Interception>();
container.Configure<Interception>().SetInterceptorFor<A2>(new VirtualMethodInterceptor());

Le he indicado a Unity que para la clase A2 utilice el interceptor VirtualMethodInterceptor. Este interceptor puede interceptar todas las llamadas a métodos virtuales.

Finalmente ya podemos definir la clase A2:

[AutoPropertyChanged()]
public class A2 : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    public virtual string Name { get; set; }
}

Fijaos en las diferencias entre A2 y la clase A antigua:

A2 está decorada con el atributo AutoPropertyChangedAttribute que hemos definido antes.
La propiedad Name es virtual
No tenemos ningún código adicional para lanzar el evento PropertyChanged.

Con eso el mecanismo de intercepción está listo. Si obteneis una instancia de A2 usando el método Resolve del contenedor y miráis con el debugger de que tipo real es el objeto, veréis que no es de tipo A2, sinó de un tipo raro: el proxy que crea Unity para poder interceptar los métodos virtuales (comparad el wach para a2 y a2newed:

2. Implementando el código en nuestro Handler

Vamos a modificar el método Invoke de AutoNotifyPropertyHandler para que lance el evento cada vez que se llame a un set de una propiedad… La clase completa queda tal y como sigue: Básicamente en el método Invoke, miramos si el nombre del método que se ha llamado empieza por “set_”, y si es el caso asumimos que es el Setter de una propiedad. Recogemos el valor actual de la propiedad usando reflection y si no son el mismo, lanzamos el evento PropertyChanged usando reflection. Y listos! :)

class AutoPropertyChangedHandler : ICallHandler
{
    public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
    {
        bool raiseEvt = false;
        string propName = null;
        INotifyPropertyChanged inpc = input.Target as INotifyPropertyChanged;
        if (inpc != null)
        {
            // Si el nombre del método empieza por "set_" es un Setter de propiedad
            if (input.MethodBase.Name.StartsWith("set_"))
            {
                propName = input.MethodBase.Name.Substring(4);
                MethodInfo getter = input.Target.GetType().GetProperty(propName).GetGetMethod();
                object oldValue = getter.Invoke(input.Target, null);
                object newValue = input.Arguments[0];
                // Si los valores de newValue y oldValue son distintos
                // debemos lanzar el evento (la comparación la hacemos por
                // Equals si es posible).
                raiseEvt = newValue == null ?
                    newValue != oldValue :
                    !newValue.Equals(oldValue);
            }
        }
        IMethodReturn msg = getNext()(input, getNext);
        // Si el setter no produce excepción, lanzamos el evento
        if (raiseEvt && msg.Exception == null)
        {
            RaiseEvent(inpc, propName);
        }
        return msg;
    }

    public int Order { get; set; }

    // Método que lanza el evento PropertyChanged usando reflection
    private void RaiseEvent(INotifyPropertyChanged inpc, string propertyName)
    {
        Type type = inpc.GetType();
        FieldInfo evt = null;
        // Buscamos el evento (no estará en el propio Type ya que el propio Type
        // será un proxy, pero iteraremos por los tipos base hasta encontrarlo)
        do
        {
            evt = type.GetField("PropertyChanged", BindingFlags.Instance | BindingFlags.NonPublic);
            type = type.BaseType;
        } while (evt == null && type.BaseType != null);
        // Invocamos el evento
        if (evt != null)
        {
            MulticastDelegate mcevt = evt.GetValue(inpc) as MulticastDelegate;
            if (mcevt != null)
            {
                mcevt.DynamicInvoke(inpc, new PropertyChangedEventArgs(propertyName));
            }
        }
    }
}

Ahora podemos comprobar como se lanza el evento automáticamente al modificar una propiedad de A2.

Un saludo!!!!

PD: Dije en el post introductorio que no pondría código, pero finalmente os incluyo el zip con el código de este post (en SkyDrive).

PD2: Echad un post a INotifyPropertyChanged with Unity Interception AOP del blog de Dmitry Shechtman que me ha servido de inspiración para el ejemplo (yo tenía pensado uno mucho más tonto en este primer post).

Objetos que notifican sus cambios de propiedades (0/3): Introducción

Eduard Tomàs i Avellana — Tue, 12 Jan 2010 12:01:08 GMT

Hola a todos!!! Como ha ido la despedida del 2009 y la bienvenida del 2010!!! Espero que os hayáis portado bien y que los reyes os hayan traído muuuuchos regalitos!

En este post quiero dejar de lado la serie que estaba haciendo sobre facebook connect, para ver como, gracias a Unity, podemos crear objetos que nos notifiquen cuando cambian sus propiedades, sin que nosotros debamos añadir (casi) ningún código adicional!

Pienso que es un muy buen ejemplo del poder de usar un contenedor IoC, además de resolver una situación que se da muchas veces: quiero enterarme de los cambios sobre las propiedades de un objeto, pero no quiero codificar dicho objeto de ninguna forma especial (es decir, no poner ningún tipo de código a la clase de cuyos cambios de propiedad deseo enterarme).

Donde queremos llegar…

Cuando hablamos de contenedores IoC, nos vienen a la cabeza dos grandes patrones: Dependency Injection y Service Locator… pero hay otra poderosísima razón para usarlos: las intercepciones. Esta capacidad permite “enchufar” código a los objetos en tiempo de ejecución, lo que permite añadir capacidades de AOP.

En este caso vamos a configurar la intercepción de Unity, para enchufar código cada vez que se lea/modifique una propiedad de un objeto. Dicho código nos notificará la lectura o escritura de la propiedad.

Además vamos a hacerlo configurable, de forma que no recibamos notificaciones de todas las propiedades, sino sólo de aquellas que nos interesen! La configuración de què propiedades queremos recibir notificación vamos a tenerla en otra clase. El objetivo es llegar a un código como el que sigue:

[PropertyNotifier(typeof(UfoNotifications))]
public class Ufo
{
    public virtual string Name { get; set; }
    public virtual int Edad { get; set; }
}

public class UfoNotifications : PropertyNotifications<Ufo>
{
    public UfoNotifications()
    {
        this.OnProperty(x => x.Name).Set.Notify.WithParameters();
        this.OnProperty(x => x.Name).Get.Notify.WithoutParameters();
        this.OnProperty(x => x.Edad).Get.Notify.WithoutParameters();
    }
}

El primer código nos define una clase Ufo. Es una clase totalmente normal, salvo por dos detalles:

El atributo PropertyNotifier nos indica que queremos recibir notificaciones cuando se lean/modifiquen propiedades de dicha clase, y indica que la configuración sobre cuales son las propiedades que deseamos notificar se encuentra en la clase UfoNotifications
Todas las propiedades son virtuales.

El segundo código contiene la configuración sobre qué propiedades y qué notificaciones queremos recibir. En este caso usamos una aproximación tipo fluent interface cuya ventaja principal es que el código es mucho más fácil de leer (y de escribir).

Esta serie va a constar de tres posts que publicaré en breve (a medida que publique los posts iré modificando éste para añadir los enlaces):

Como configurar el mecanismo de intercepción de Unity para enchufar nuestro código (Añadido el 13/01/2009).
Como podemos notificar los cambios de propiedades, sin obligar a que quien quiera recibirlos tenga que tener una referencia al objeto que los notifica (lo que nos impide usar eventos tradicionales de .NET) (Añadido el 14/01/2009).
Como crear la fluent interface para configurar las notificacioes

~~No voy a adjuntar código en cada post porque sólo tengo la solución completa implementada… en el último post adjuntaré todo el código, junto con un ejemplo.~~ Al final sí que adjunto un zip en cada post :)

Nos leemos!

Evita las dependencias con tu contendor de IoC

Eduard Tomàs i Avellana — Tue, 01 Dec 2009 15:16:21 GMT

Usar un contenedor de IoC es una práctica más que recomendable, pero al hacerlo es muy fácil caer en el anti-patrón de dependencia con el contenedor. Ese patrón se manifesta de varias formas sútiles, y aunque hay algunos casos en que pueda ser aceptable, en la gran mayoría indica una mala práctica que debemos revisar.

¿Que tiene de malo este código?

// IS1 y IS2 son dos interfaces cualesquiera
// S1 y S2 son dos clases que implementan dichas interfaces
class A
{
    IS1 s1;
    IS2 s2;
    public A(IUnityContainer container)
    {
        this.s1 = container.Resolve<IS1>();
        this.s2 = container.Resolve<IS2>();
    }
}

class Program
{
    static void Main(string[] args)
    {
        IUnityContainer ctr = new UnityContainer();
        ctr.RegisterType<IS1, S1>();
        ctr.RegisterType<IS2, S2>();
        A a = ctr.Resolve<A>();
    }
}

El código funciona correctamente, pero ¡ojo! Tenemos una dependencia directa de la clase A hacia IUnityContainer. Realmente la clase A depende de IUnityContainer o bien depende de IS1 y IS2? La realidad es que las dependencias de la clase A son IS1 e IS2.

1. La visión filosófica del asunto

Si yo leo el constructor de la clase A y veo que pone:

public A(IUnityContainer container)
{
    // Código...
}

Debo leer todo el código del constructor para ver las dependencias reales de la clase A. Por otro lado si el constructor fuese:

public A(IS1 s1, IS2 s2)
{
    // Código
}

Ahora queda mucho más claro que las dependencias reales de la clase A son IS1 y IS2.

En resumen: evitad en lo máximo de lo posible pasar el propio contenedor como parámetro de los constructores. En su lugar pasad las dependencias reales y dejad que el contenedor las inyecte.

Y obviamente evitad (casi) siempre un código como:

class A
{
    IUnityContainer container;
    public A(IUnityContainer container)
    {
        this.container = container;
    }
    // Código
}

¡Ahí estamos todavía más vendidos! Para averiguar las dependencias reales de la clase A, ahora debemos mirar todo el código de la clase A, puesto que en cualquier sitio alguien puede hacer un resolve (antes de que alguien salte por las paredes que eche un vistazo al punto 4 del post, por favor :p).

La visión “filosófica” me indica que si la clase A debería depender solo de IS1 e IS2 no es posible que me aparezca una dependencia sobre IUnityContainer. Necesita la clase A a IUnityContainer para hacer su trabajo? No, verdad? Pues eso.

Incluso aunque tengas claro, clarísimo que nunca vas a abandonar Unity (él no lo haría! :p) este código no huele nada bien.

2. La visión práctica

Algún dia quizá te canses e Unity y te decidas a usar por ejemplo, Windsor Container… Este cambio debería ser un cambio sencillo: un cambio en el bootstrapper de tu aplicación, y donde instanciabas Unity ahora instancias Windsor, lo configuras y listo!

Listo? Listo sólo si tus clases no dependen de IUnityContainer, porque en caso contrario… bueno, puedes tener un buen problemilla ;)

3. Algunos detalles...

Antes he comentado que este anti-patrón puede aparecer de formas realmente sutiles:

class A
{
    public A() 
    {
        //...
    }
    [Dependency()]
    public IS1 S1 { get; set; }
    // Más código
}

¿Es correcto este código? Mejor que el código anterior donde recibíamos IUnityContainer como parámetro si que es, porque no tenemos ninguna dependencia directa contra Unity… Pero realmente si que estamos dependiendo de Unity: Sólo Unity entenderá el atributo [Dependency()] para inyectarnos la propiedad S1. Así que a la práctica estamos como en el caso anterior.

Ahora bien, la diferencia fundamental es que, en mi opinión, que la clase A reciba IUnityContainer como parámetro rebela un mal diseño, mientras que en este caso la dependencia nos aparece porque no existe ningún mecanismo estándar para especificar que queremos que una propiedad sea inyectada (por lo que cada contenedor usa su propio mecanismo).

Si tienes claro, clarísimo que nunca abandonarás Unity, entonces no hay problema alguno en este código. Por otro lado si no quieres atarte al contenedor entonces este código no te sirve (echa un vistazo a mi post Unity? Sí gracias, pero no me abraces demasiado para ver más detalles al respecto).

4. Ya, pero yo uso el patrón Service Locator

Todo lo que hemos hablado hasta ahora afecta sobre todo en aquellos casos en que usábamos inyección de dependencias, pero existe otro patrón íntimamente relacionado: el service locator. En este patrón tenemos un objeto (el propio service locator) que se encarga de devolvernos referencias a servicios.

Es común que el propio contenedor de IoC se use como service locator, porque ofrece soporte directo para ello. Sin embargo no es una buena opción… porque conduce inevitablemente a situaciones como las que hemos visto, en concreto a situaciones como esta:

class A
{
    private IUnityContainer serviceLocator;
    public A(IUnityContainer serviceLocator) 
    {
        this.serviceLocator = serviceLocator;
    }
    void foo()
    {
        // obtengo los servicios...
        var logSvc = serviceLocator.Resolve<ILogService>();
        var locSvc = serviceLocator.Resolve<ILocalizationService>();
        // hago cosas con mis servicios
    }
}

Este código es prácticamente igual al que os decía que debéis evitar a toda costa. Podríamos pasar ILogService e ILocalizationService en el constructor, pero ahora imaginad que tenemos muchos servicios y nuestras clases los usan todos (en un proyecto en el que estoy trabajando manejamos decenas de servicios, y además es común que las clases usen muchos de los servicios sólo en un método).

El error aquí, está en usar el propio contenedor como Service Locator: lo hacemos porque es rápido y cómodo ya que el contenedor nos ofrece soporte para ello, pero a cambio nos estamos atando al contenedor… Nosotros no queremos una dependencia contra IUnityContainer, sinó una dependencia contra el service locator. Y qué es el service locator? Pues algo distinto al propio contenedor. Por ejemplo, eso:

interface IServiceLocator
{
    T GetService<T>() where T : class;
}
class ServiceLocator : IServiceLocator
{
    private IUnityContainer container;
    public ServiceLocator(IUnityContainer container)
    {
        this.container = container;
    }

    public T GetService<T>() where T : class
    {
        return this.container.Resolve<T>();
    }
}

La clase ServiceLocator si que depende de Unity (ahí si que es inevitable la dependencia). Ahora la clase A la podemos reescribir como:

class A
{
    private IServiceLocator serviceLocator;
    public A(IServiceLocator serviceLocator) 
    {
        this.serviceLocator = serviceLocator;
    }
    void foo()
    {
        // obtengo los servicios...
        var logSvc = serviceLocator.GetService<ILogService>();
        var locSvc = serviceLocator.GetService<ILocalizationService>();
        // hago cosas con mis servicios
    }
}

Y la clase A ya no depende de IUnityContainer: lo hace de IServiceLocator, lo que es aceptable y totalmente lógico.

Además, tener nuestra propia implementación del service locator nos permite adaptarlo a nuestras necesidades (p. ej. ¿qué hacer si nos piden un servicio que no está registrado?).

Así pues, usar el patrón service locator no es excusa para tener nuestro código lleno de dependencias contra el contenedor de IoC.

¿Opiniones? ;-)

Un saludo a todos!

Lifetime Managers en Unity o ¿como sé que eso que me das es un singleton?

Eduard Tomàs i Avellana — Mon, 26 Oct 2009 16:31:51 GMT

Los que leais habitualmente mi blog (¡muchas gracias!) habreis visto que tengo varias entradas sobre unity el contenedor IoC de la gente de patterns & practices. En ellas he ido comentando varios aspectos más o menos avanzados del contenedor y de los patrones IoC associados.

En este post quiero hablaros un poco de los “lifetime managers”, objetos que le indican a Unity si cuando debe resolver un objeto debe crear uno nuevo o bien devolver uno existente.

Resumiendo mucho podemos afirmar que:

Con RegisterType<IA, A>() lo que hacemos es registrar un mapeo de la interfaz IA a la clase A: cada vez que pidamos un objeto IA, usando Resolve<IA>(), el contenedor nos devolverá un nuevo objeto A.
Con RegisterInstance<IA>(IA instance) lo que hacemos es registrar un singleton de la interfaz IA. Cada vez que pidamos un objeto IA, el contenedor nos devolverá el mismo objeto: el que hemos pasado como parámetro a RegisterInstance.

La realidad es, como casi siempre, un poco más compleja. Unity no distingue solamente los casos “crear un objeto cada vez” o “devolver siempre el mismo objeto”, sino que la decisión de si se debe crear un objeto nuevo o no se deriva en otra clase: el lifetime manager. De serie con Unity vienen 3 lifetime managers distintos:

TransientLifetimeManager: Cada vez que tengamos que devolver un objeto crearemos uno nuevo.
ContainerControlledLifetimeManager: Devolveremos siempre el mismo objeto (singleton).
PerThreadLifetimeManager: Devolveremos siempre el mismo objeto, pero crearemos un objeto para cada thread (singleton a nivel de thread).
ExternallyControlledLifetimeManager: Cada vez que tengamos que devolver un objeto devolveremos el mismo, si este sigue vivo (es decir el garbage collector no lo ha “recogido”). Obviamente Unity no mantiene una referencia al objeto sino una WeakReference, ya que en caso contrario el objeto estaría vivo “para siempre” dentro de Unity.

Tomemos la siguiente interfaz IA, y la clase A que la implementa:

public interface IA
{
    Guid Id {get;}
}
public class A : IA
{
    public Guid Id {get; private set;}
    public A()
    {
        this.Id = Guid.NewGuid();
    }
}

Cada objeto A creado tendrá su propio Id único.

Ahora miremos el siguiente código:

IUnityContainer container = new UnityContainer();

container.RegisterType<IA, A>(new ContainerControlledLifetimeManager());
IA a1 = container.Resolve<IA>();
IA a2 = container.Resolve<IA>();
Console.WriteLine("a1: " + a1.Id.ToString());
Console.WriteLine("a2: " + a2.Id.ToString());

Si ejecutáis el siguiente código observareis que el ID es el mismo: Unity nos ha devuelto el mismo objeto para las dos llamadas a container.Resolve<IA>(). Esto ha sido porque hemos especificado un ContainerControlledLifetimeManager como parámetro a la llamada RegisterType.

Si ahora modificamos el ContainerControlledLifetimeManager por un ExternallyControlledLifetimeManager el resultado es el mismo: ambos Resolve reciben el mismo objeto.

Ahora bien, si forzamos una recolección del Garbage Collector:

IUnityContainer container = new UnityContainer();
container.RegisterType<IA, A>(new ExternallyControlledLifetimeManager());
IA a1 = container.Resolve<IA>();
Console.WriteLine("a1: " + a1.Id.ToString());
a1 = null;      // Importante! Si no es null, el GC no puede recojer el objeto!
GC.Collect();
IA a2 = container.Resolve<IA>();
Console.WriteLine("a2: " + a2.Id.ToString());

Ahora podemos observar como la segunda llamada a Resolve ha obtenido un objeto distinto al de la primera llamada (ya que el Garbage Collector ha eliminado el primer objeto).

Crear nuestros propios lifetime managers

Ahora que hemos visto que la realidad es un poco más divertida, la siguiente pregunta es: podemos crear nuestros propios lifetime managers? Y la respuesta es sí!

Para ello simplemente debemos crearnos una clase que herede LifetimeManager y que implemente los métodos:

SetValue: Que invoca Unity cuando ha creado el objeto. En este método podemos guardarnos el objeto creado.
GetValue: Donde devolvemos el objeto o bien null, para que Unity cree uno de nuevo (y luego nos invoque SetValue).
RemoveValue: Cuando se elimina un objeto

Una nota importante sobre RemoveValue: Unity nunca llama a este método, está ahí para que nosotros podamos eliminar objetos de Unity, siempre y cuando tengamos acceso al Lifetime manager.

Veamos un posible ejemplo de un Lifetime manager:

public class CustomLifetimeManager : LifetimeManager
  {
      private object[] values;
      int idx = 0;

      public CustomLifetimeManager(int instances)
      {
          values = new object[instances];
          idx = -1;
      }

      public override void SetValue(object newValue)
      {
          values[idx] = newValue;
      }

      public override object GetValue()
      {
          idx = (idx + 1) % values.Length;
          object value = values[idx];
          return value;
      }

      public override void RemoveValue()
      {
          object value = values[idx];
          values[idx] = null;
          idx = (idx + 1) % values.Length;
          if (value is IDisposable)
          {
              ((IDisposable)value).Dispose();
          }
      }
  }

El código se comenta casi solo, no? Este lifetime manager guarda x instancias del objeto, eso significa que Unity nos devolverá hasta x objetos distintos, y luego empezará a repetirlos.

P.ej. dado el siguiente código:

IUnityContainer container = new UnityContainer();
CustomLifetimeManager lft = new CustomLifetimeManager(3);

container.RegisterType<IA, A>(lft);

IA a1 = container.Resolve<IA>();
IA a2 = container.Resolve<IA>();
IA a3 = container.Resolve<IA>();
// Repes!
IA a4 = container.Resolve<IA>();
IA a5 = container.Resolve<IA>();
IA a6 = container.Resolve<IA>();

Hemos configurado nuestro CustomLifetimeManager para que nos de hasta tres objetos distintos. Los tres primeros Resolve recibirán cada uno un objeto nuevo distinto… pero luego el cuarto resolve recibirá de nuevo el primer objeto, el quinto recibirá el segundo y así sucesivamente: hemos creado un pool de objetos.

Como veis es realmente fácil, crearos vuestros propios lifetime managers, lo que os permite personalizar al máximo cuando Unity debe crear un objeto nuevo o devolver uno ya existente!

Un saludo!

¿MVP e IoC trabajando juntos? ¡Pues claro!

Eduard Tomàs i Avellana — Tue, 13 Oct 2009 10:09:01 GMT

Un comentario de Galcet en mi post “Como independizar tu capa lógica de tu capa de presentación” decía que el entendía por separado los conceptos de IoC y los de MVC pero que no veía como podían trabajar juntos… El motivo de este post es para comentar precisamente esto: no sólo cómo MVC e IoC pueden trabajar juntos sinó las ventajas que la combinación de ambos patrones nos aporta.

Galcet no comentaba si se refería a aplicaciones desktop o web. En este post voy a tratar aplicaciones de escritorio (por lo que me centraré en el patrón MVP más que en el MVC dado que, en mi opinión, MVP aplica mejor que MVC en aplicaciones desktop). En aplicaciones web, si usamos ASP.NET MVC el tema se simplifica mucho, dado que ASP.NET MVC está “preparado” para que sea muy fácil crear nuestros controladores mediante cualquier contenedor IoC.

La filosofía CAB + SCSF

CAB (o Composite UI Application Block) es un framework para el desarrollo de aplicaciones de escritorio winforms con interfaz de usuario compleja. Se basa en el patrón MVP y se compone de varios assemblies y una guía de buenas prácticas. Aunque puede usarse sola, suele combinarse con SCSF (Smart Client Software Factory), un conjunto de guías, librerías y buenas prácticas para la creación de aplicaciones winforms complejas. La recomendación de SCSF para la interfaz de usuario es usar CAB, y de hecho extiende CAB. No voy a hablar aquí ni de CAB ni de SCSF (hay varios tutoriales en internet), sino de como CAB y SCSF afrontan el uso de IoC junto con MVP.

La filosofía de SCSF es que nosotros creamos las vistas y las vistas crean a su presenter asociado. El código equivalente usando Unity sería algo parecido a:

public class View : UserControl, IView
{    
    public View ()    
    {        
        InitializeComponents();        
        // Resto de código...    
    }    
    private IMyPresenter _presenter;
    [Dependency()]
    public IMyPresenter Presenter
    {
        get { return _presenter;}
        set
        {
            _presenter = value;
            _presenter.View = this;
        }
    }
}
public class MyPresenter : IPresenter
{
    public IView View { get; set;}    
}

El contenedor debe tener registrado el mapping entre las interfaces y las clases:

container.RegisterType<IPresenter, MyPresenter>();

container.RegisterType<IView, View>();
// Creamos la vista
var view = container.Resolve<IView>();

Al llamar al método Resolve, Unity consulta sus mappings y llega a la conclusión de que debe crear un objeto View. La clase View tiene una propiedad “Presenter” decorada con [Dependency()], por lo que Unity debe inyectar un valor a esta propiedad. La propiedad es de tipo IMyPresenter, Unity consulta sus mappings y vee que debe crear un objeto de la clase MyPresenter. Luego en el setter de la propiedad “Presenter” la vista se asigna a si misma como vista del presenter recién creado.

A lo mejor alguien se pregunta porque no usamos inyección de dependencias en el constructor del presenter, es decir que en lugar de que nuestro presenter declare una propiedad que reciba la vista y rellenar esta propiedad desde la propia vista, declaramos la vista en el constructor y que Unity se encargue de todo:

public class View : UserControl, IView
{        
    public View ()        
    {                
        InitializeComponents();                
        // Resto de código...        
    }        
    private IMyPresenter _presenter;    
    [Dependency()]    
    public IMyPresenter Presenter { get; set;}
}
public class MyPresenter : IPresenter
{    
    public MyPresenter (IView view)
    {
        // Nos guardamos la vista...
    }
}

¿Qué problema hay en este código? A priori puede parecer que ninguno, pero si repasamos como actuaría Unity:

Al llamar a Resolve<IView> Unity consulta sus mappings y ve que debe crear un objeto de la clase View
Al inyectar la propiedad Presenter, Unity consulta sus mappings y ve que debe crear un objeto de la clase MyPresenter
Al intentar crear un objeto MyPresenter, Unity observa que el constructor recibe un IView y que debe inyectarlo.
Así pues, Unity consulta sus mappings y crea un nuevo objeto View que inyectará en el constructor del MyPresenter.

Suponiendo que todo esto no terminase en un Stack Overflow, en todo caso el objeto MyPresenter recibiría un objeto View distinto del que devolvería la llamada a Resolve.

El “problema” de Visual Studio

¿Porque ha optado CAB por esta filosofía? ¿Porque las vistas crean a los presenters y no al revés? ¿Porque la inyección de dependencias es por propiedades y no en el constructor? La respuesta a todos estos interrogantes se llama Visual Studio.

Me explico: si tenemos una vista (o sea un UserControl) llamada View, cuando la arrastramos dentro de un formulario, o de un panel Visual Studio genera un código parecido a:

View view1 = new View();
panel1.Controls.Add(view1);

¿Observáis el problema? Visual Studio ha creado una instancia de la vista, usando new, no usando el método Resolve del contenedor de IoC, por lo tanto nos podemos olvidar de la inyección de dependencias, por lo que efectivamente nuestro presenter no estará creado.

¿Como podemos solucionar este problema? Bueno… todos los controladores IoC permiten “inicializar” un objeto ya creado, entendiendo por “inicializar” inyectar todas las dependencias que este objeto necesita (en el caso de nuestras vistas, la propiedad “Presenter”). En el caso de Unity este método se llama BuildUp, y se le pasa la instancia del objeto a inicializar. Lo que debemos hacer es inicializar todos los controles que estén en el formulario, lo que podemos hacer en el método Main:

[STAThread]
static void Main()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Form1 frm = new Form1();
    IUnityContainer container = new UnityContainer();
    frm.BuildUpControls(container);
    Application.Run(frm);
}

Donde el método “BuildUpControls” es un método de extensión definido de la siguiente manera:

public static class FormExtensions
{
    public static void BuildUpControls (this Control self,
        IUnityContainer container)
    {
        container.BuildUp(self);
        foreach (Control control in self.Controls)
        {
            control.BuildUpControls(container);
        }
    }
}

El método BuildUpControls va recorriendo recursivamente la colección “Controls” para llamar al método “BuildUp” del contenedor con todos los controles creados. En este caso no miramos nada más, por lo que inicializamos todos los controles (incluso las labels, los textboxes…), lo que es excesivo. Un refinamiento es inicializar sólo aquellos controles que sean “vistas”. Por ejemplo, CAB para saber que un control es una “vista” y que debe ser inicializado obliga a decorarlo con el atributo [SmartPart].

Evidentemente si nosotros mismos añadimos en run-time una vista debemos inicializarla “manualmente”:

Subview view = new Subview();
view.BuildUpControls(container);
// O bien...
Subview view = container.Resolve<Subview>();

Eso mismo ocurre en CAB: si en CAB creamos una vista de forma programática también debemos “inicializarla”. CAB gestiona la inicialización de una forma totalmente distinta, pero la filosofía es la misma (que es lo que intento contar).

Pues bueno… hemos visto como podemos combinar el uso de un contenedor IoC (como siempre en mi caso Unity :p) junto con el patrón MVP. Fijaos que los presenters si que están creados por Unity, por lo que pueden recibir dependencias inyectadas en el constructor (p.ej. a un servicio de log).

Un saludo!

IoC o el poder de ceder el control (ii): Dependency Injection

Eduard Tomàs i Avellana — Thu, 08 Oct 2009 10:11:04 GMT

Hace ya algún tiempecillo publiqué por aquí un post sobre IoC, titulado IoC o el poder de ceder el control. En el post mencionaba dos de los patrones clásicos asociados con IoC, el service locator y la inyección de dependencias (dependency injection), pero luego sólo me centraba en Service Locator. Un par de comentarios en dicho post decían si era posible algo similar pero explicando la inyección de dependencias, así que a ello vamos ;-)

Dependencias de una clase

Para entender como funciona la inyección de dependencias tenemos que tener claro que entendemos por dependencias de una clase: Básicamente una clase tiene dependencias con todas las otras clase que utilice, ya sea reciba objetos de dicha clase como parámetros, los devuelva como valores de retorno o cree variables locales o de clase.

Las dependencias no son nada malo y de hecho no son evitables: es evidente que las clases cooperan unas con otras para realizar alguna acción conjunta, así que es lógico que nuestro código depende de otras clases. Lo que debe preocuparnos es el acoplamiento de nuestro código con estas dependencias, o dicho de otro modo: cuanto nos costaría cambiar nuestra clase para que en lugar de depender de una clase X, dependiese de otra clase Y que ofrece la misma funcionalidad. Si has de modificar muchas líneas de código es que tienes un alto acoplamiento (y eso sí que es malo). El objetivo de la inyección de dependencias es facilitarte conseguir un acoplamiento lo más bajo posible.

Alto acoplamiento: uso directo de clases

El nivel de acoplamiento mayor es cuando nuestros métodos trabajan con parámetros cuyo tipo es una clase:

public class X
{
    public MyLogClass Logger { get; private set;}
    public X (MyLogClass logger)
    {
        this.Logger = logger;
    }
}

La clase X tiene un alto acoplamiento con la clase MyLogClass. Si quisiéramos cambiar MyLogClass por otra clase distinta, llamésmole MyLogClass2 que tenga la misma funcionalidad deberemos modificar la clase X para que la propiedad Logger sea de tipo MyLogClass, asi como modificar el constructor… Parece sencillo, pero tened en cuenta que nuestra clase X será llamada por varias clases distintas. Todas las clases que crean un objeto de X, crearán un objeto MyLogClass para pasarlo como parámetro al constructor: deberemos cambiar también todas estas clases.

Un cambio que debería ser fácil y que debería afectar sólo a una clase, se convierte, por culpa de alto acoplamiento, en un cambio complejo, que afecta a multitud de clases.

Acoplamiento medio: Interfaces

Las interfaces ayudan solucionar el problema. Podemos definir la clase X para que trabaje con interfaces:

public class X
{
    public ILogger Logger { get; private set;}
    public X (ILogger logger)
    {
        this.Logger = logger;
    }
}

Ahora la clase X no tiene dependencia alguna con MyLogClass. Podemos utilizar MyLogClass, MyLogClass2 o cualquier clase que implemente ILogger.

Pero el problema no está resuelto al 100%. Para crear objetos de la clase X, debemos pasarle en el constructor un objeto de una clase que implemente ILogger:

MyLogClass logger = new MyLogClass();
X x = new X(logger);

Es decir la clase X no depende de MyLogClass, pero todas aquellas clases que crean objetos de la clase X sí, ya que deben crear un MyLogClass para pasarlo como parámetro al constructor. De nuevo modificar MyLogClass por MyLogClass2 implica localizar todos aquellos sitios donde se crean objetos de X y modificarlo.

Acoplamiento bajo: Interfaces + Factoría

Llegados a este punto alguien puede tener la idea “hey! porque no creamos una factoria de ILogger, que sea la responsable de crear los objetos?”. Es una gran idea ya que mueve todas las dependencias a la clase en UN sólo sitio, la factoría:

public static class ILoggerFactory
{
    public static ILogger GetLogger()
    {
        return new MyLogClass();
    }
}

// ... Luego en cualquier otro sitio ...
X x = new X (ILoggerFactory.GetLogger());

Ahora si en lugar de querer usar MyLogClass queremos usar MyLogClass2 sólo debemos modificar la factoría.

Hey! Y todo eso sin usar IoC… entonces para que el post? Bueno… imagina que por cualquier razón, debes modificar el constructor de X para que acepte algún otro parámetro:

public class X
{
    public X (ILogger log, IFormatter frm);    
}

Sigue imaginando que, por la razón que sea, no puedes seguir teniendo el constructor con un solo parámetro ILogger, ya que no puedes asignar ningún valor por defecto a IFormatter. Pues bien… en este caso de nuevo debes volver a localizar todas las llamadas al constructor de X y modificarlas para pasar el nuevo parámetro (que por supuesto sacarás de otra factoría que crearás).

Por suerte no estamos en un callejón sin salida: la inyección de dependencias viene para solucionar este pequeño problema.

Acoplamiento muy bajo: Inyección de dependencias

La inyección de dependencias se basa en el mismo principio que la factoría: No creas tu los objetos directamente, sinó que delegas esta responsabilidad en alguien. La diferencia respecto a la factoría tradicional, es que este alguien es un contenedor de IoC, capaz de crear todos aquellos parámetros necesarios e inyectarlos en el constructor. Si añades un parámetro nuevo, apenas deberás hacer nada: el contenedor de IoC automáticamente sabrá inyectar este nuevo parámetro.

Vamos a ver un ejemplo usando Unity, el contenedor IoC de la gente de Patterns & Practices. Primero comento muy rápidamente los conceptos básicos de Unity.

La gracia está en mapear un tipo a una interfaz, con esto le decimos al contenedor que cuando pidamos objetos de una interfaz nos devuelva objetos de una clase determinada. Esto en Unity se consigue con el método RegisterType:

IUnityContainer container = new UnityContainer();
container.RegisterType<ILogger, MyLogClass>();

Cuando pidamos un ILogger, Unity nos devolverá un MyLogClass… Y como le pedimos a Unity un ILogger? Pues usando el método Resolve:

ILogger logger = container.Resolve<ILogger>();

Hasta aquí todo muy parecido a la factoría. Ahora viene lo bueno: Si tenemos mappings registrados en Unity para las interfaces, Unity puede inyectar estos mappings en cualquier constructor. Es decir:

container.RegisterType<ILogger, MyLogClass>();
container.RegisterType<IFormatter, MyFormatClass>();
X x = container.Resolve<X>();

Con las dos primeras líneas hemos configurado nuestro contenedor de IoC para que sepa que devolver cuando se le pida un ILogger y un IFormatter. Con la tercera línea estamos pidiendo un objeto de tipo X. Entonces Unity hace lo siguiente:

Mira si tiene algún mapeo que mapee X a una clase en concreto (en principio Unity no sabe que X es una clase y no una interfaz).
Al no tenerlo, deduce que es una clase y que debe crear un objeto de la clase X. Para ello inspecciona la clase X, y ve que el constructor requiere dos parámetros, un ILogger y un IFormatter.
1. Unity resuelve el primer parámetro
2. Unity resuelve el segundo parámetro
3. Unity pasa los valores de los dos parámetros resueltos al constructor de la clase X y devuelve el objeto X creado. Es decir, Unity inyecta los parámetros necesarios en el constructor.

Es decir, lo que Unity hace por nosotros es equivalente a si hubieramos hecho:

ILogger p1 = container.Resolve<ILogger>();
IFormatter p2 = container.Resolve<IFormatter>();
X x = new X(p1, p2);

Llegados a este punto… si se modificase el constructor de la clase X para hacer aparecer un tercer parámetro… tan sólo debemos hacer una modificación en nuestro código: Donde configuramos el contenedor de Unity, poner una llamada más a RegisterType(), para que Unity sepa que devolver cuando se encuentre un parámetro de dicho tipo. Pero dado que en nuestro códgo siempre obtenemos instancias de X llamando a container.Resolve<X>(), no deberemos modificar ninguna línea más de nuestro código.

Llegados a este punto, comentaros dos cosillas:

Lo que hemos visto se llama inyección de dependencias en el constructor, y es uno de los mecanismos más normales. Otra forma común de inyectar dependencias es usar propiedades: es decir, el contenedor IoC al crear el objeto, inyecta valores en todas las propiedades que nosotros le indiquemos.
Que ocurre en aquellos objetos que por cualquier razón NO pueden ser creados por el contenedor (p.ej. objetos que un framework cree por nostros)? Podemos hacer que estos objetos reciban inyección de dependencias?

La respuesta al punto (2) la da el punto (1): Podemos utilizar inyección de dependencias en propiedades y luego, una vez tenemos el objeto ya creado, decirle al contenedor IoC que inyecte las dependencias pendientes. Esto en Unity se hace mediante el método BuildUp, que toma un objeto e inyecta las dependencias pendientes. Por ejemplo imaginad que deserializamos un objeto y queremos que el objeto deserializado reciba dependencias del contenedor de IoC. Es evidente que no podemos poner las dependencias en el constructor (porque no controlamos quien crea el objeto), pero podemos poner las dependencias en propiedades y una vez tenemos el objeto indicarle al contenedor de IoC que inyecte dichas propiedades. Esto en Unity se consigue mediante el método BuildUp.

public class X
{
    // Código variado...
    
    // El atributo Dependency indica a Unity que la propiedad debe
    // ser inyectada
    [Dependency()]
    [XmlIgnore()]
    public ILogger Logger { get; set;}    
}

// En cualquier otro sitio...

X x = null;
XmlSerializer ser = new XmlSerializer(typeof(X));
x = (X)ser.Deserialize(myStream);
// Inyectamos las propiedades
container.BuildUp(x);

Cuando leemos el stream myStream, el propio XmlSerializer nos crea un objeto de la clase X. Luego al llamar al método BuildUp, es cuando el contenedor de IoC inyectará las propiedades.

Así es como funciona (más o menos :p) la inyección de dependencias.

Un saludo a todos!

ASP.NET MVC Custom Action Filters y IoC

Eduard Tomàs i Avellana — Fri, 02 Oct 2009 12:48:12 GMT

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!!!!!

Unity, Proxies, AOP y un poco de todo eso…

Eduard Tomàs i Avellana — Thu, 24 Sep 2009 09:34:00 GMT

En mi opinión, usar un contenedor de IoC hoy en día, no es una opción sinó una obligación. Las ventajas que nos ofrecen son incotestables. Los patrones Service Locator y Dependency Injection nos permiten desacoplar nuestro código, y son la base para poder trabajar de forma modular y poder generar unos tests unitarios de forma más sencilla. Pero hoy no quiero hablaros de ninguno de estos patrones, sinó de otra de las capacidades de los contenedores de IoC: la generación de proxies.

Con esta técnica lo que podemos hacer es inyectar nuestro propio código para que se ejecute antes o después del código que contenga la clase en particular. Esto, si lo combinamos con los atributos nos proporciona unas capacidades potentísimas para poder tener programación orientada a aspectos.

Vamos a ver como realizar esta técnica usando Unity, pero no es exclusiva de este contenedor de IoC, otros contenedores como Windsor también tienen esta capacidad.

El mecanismo en Unity que nos permite generar proxies a partir de clases del usuario, se llama intercepción. Cuando creamos una intercepción en Unity debemos definir básicamente dos cosas:

Qué ocurre cuando un método es interceptado (la política de intercepción).
Cómo se intercepta un método (el interceptor).

Vamos a ver paso a paso como funciona el mecanimso.

1. Preparación del entorno

Vamos a crear una aplicación de consola, y añadimos las referencias a todos los ensamblados de Unity.

Luego vamos a crear una interfaz, y la clase que vamos a interceptar:

public interface IMyInterface
{
    string SomeProperty { get; set; }
}
public class MyClass : IMyInterface
{
    public string SomeProperty { get; set; }
}

Finalmente, en el método Main() creamos un contenedor de Unity y registramos el mapping entre la interfaz y el tipo:

static void Main(string[] args)
{
    UnityContainer uc = new UnityContainer();
    uc.RegisterType<IMyInterface, MyClass>();
}

Ahora estamos listos para empezar!!!

2. Configuración de Unity para que use un interceptor

Vamos a configurar Unity para que use un interceptor cuando se resuelva la interfaz IMyInterface. Para ello, primero debemos añadir la extensión de intercepción a Untiy y luego configurarla:

static void Main(string[] args)
{
    UnityContainer uc = new UnityContainer();
    uc.RegisterType<IMyInterface, MyClass>();
    // Añadimos la extensión de intercepción
    uc.AddNewExtension<Interception>();
    // La configuramos para que nos devuelva
    // un TransparentProxy cuando resolvamos IMyInterface
    uc.Configure<Interception>().
    SetInterceptorFor<IMyInterface>
        (new TransparentProxyInterceptor());
    var u = uc.Resolve<IMyInterface>();
    u.SomeProperty = "test";
}

Vamos a meter un breakpoint en la última línea y a ejecutar el código, para ver si Unity ha echo algo:

Vaya… pues no parece que haya hecho nada, la verdad. La variable u es de tipo MyClass, no parece haber ningún proxy por ahí…

Es normal, ya que hemos configurado Unity para que use un TransparentProxy al resolver la interfaz IMyInterface, pero no lo hemos dicho que debe hacer Unity con este proxy, así que simplemente para no hacer nada, no crea ni el proxy…

3. Crear el interceptor

Ha llegado el momento de crear un interceptor, que defina que ocurre cuando se intercepta un método o propiedad de la clase. Para ello vamos a crear una clase nueva que implementa la interfaz ICallHandler:

public class MyHandler : ICallHandler
{
    public IMethodReturn Invoke(IMethodInvocation input, 
        GetNextHandlerDelegate getNext)
    {
        IMethodReturn msg = getNext()(input, getNext);
        return msg;
     }
        public int Order { get; set; }
    }

Esta es la implementación básica por defecto de ICallHandler: no estamos haciendo nada, salvo pasar la llamada a la propiedad real de la clase. Es decir, nuestro interceptor no está haciendo realmente nada.

Podemos añadir aquí el código que queramos, p.ej:

public IMethodReturn Invoke(IMethodInvocation input, 
     GetNextHandlerDelegate getNext)
{
    Console.WriteLine("Se ha llamado {0} con valor {1}", 
     input.MethodBase.Name, input.Inputs[0]);
    IMethodReturn msg = getNext()(input, getNext);
    return msg;
}

4. Indicar que métodos / propiedades queremos interceptar

Tenemos a Unity configurado para usar intercepción, y un interceptor creado… ahora nos queda finalmente vincular este interceptor con las propiedades o métodos que deseemos.

Para ello podemos usar los atributos: la idea es decorar cada propiedad o método con un atributo que indique que interceptor se usa para dicha propiedad y además configure dicho interceptor. Así, generalmente, vamos a usar un atributo para cada interceptor. En nuestro caso tenemos un sólo interceptor (MyHandler), así que añadiremos un atributo MyHandlerAttribute.

Para ello vamos a crear una clase que derive de HandlerAttribute (la cual a su vez deriva de Attribute), y redefinir el método CreateHandler. En este método debemos devolver el Handler que deseemos:

[AttributeUsage(AttributeTargets.Property)]
class MyHandlerAttribute : HandlerAttribute
{
    public override ICallHandler CreateHandler
        (IUnityContainer container)
    {
        return new MyHandler();
    }
}

En este caso nuestro atributo es trivial, pero en otros casos el atributo puede tener parámetros (y pasárselos al constructor del interceptor, o incluso crear un interceptor u otro en función de dichos parámetros).

5. Aplicar el atributo a las propiedades que deseemos

Para ello simplemente decoramos las propiedades (o métodos) que deseemos con el atributo:

public class MyClass : IMyInterface
{
    [MyHandler]
    public string SomeProperty { get; set; }
}

Y…. ya hemos terminado! Si colocamos un breakpoint en el mismo lugar de antes, veremos que ahora si que Unity nos ha creado un proxy:

Y si ejecutamos el programa, veréis como la salida por pantalla es la siguiente:

Se ha llamado set_SomeProperty con valor test

Nuestro interceptor ha sido llamado… hemos triunfado!!! ;-)

Si añadís una propiedad extra a la interfaz (y a la clase) y NO la decoráis con el atributo veréis que, obviamente dicha propiedad NO es interceptada.

Esta técnica tiene unas posibilidades brutales… a mi se me ocurren a brote pronte, temas de logging, seguridad, validación de propiedades… vamos, todo aquello en lo que es aplicable la programación orientada a aspectos!

Un saludo a todos! ;-)

La sencillez de una interfaz compleja

Eduard Tomàs i Avellana — Thu, 12 Mar 2009 10:11:00 GMT

Hace algún tiempecillo escribí un artículo para el e-zine de raona, que enviamos a distintos clientes. En el artículo esbozaba los patrones básicos para diseñar interfaces de usuario compuestas. Posteriormente me surgió la idea de que una ampliación de dicho artículo, donde se mostrasen ejemplos en PRISM y WPF de estos conceptos podría ser interesante. Afortunadamente en DotNetMania pensaron lo mismo y es por ello que en la revista de este marzo hay un artículo con este mismo título.

Lo que ahora sigue és el artículo original, el que escribí para el e-zine. Aunque el de DotNetMania describe las mismas ideas, ambos artículos tienen poco a ver (tanto en contenido, como en enfoque como en extensión). Como creo que el artículo del e-zine tambiém tiene su interés, me he tomado la libertad de postearlo aquí :)

PD: Por si os interesa, los distintos e-zines que vamos sacando en raona, los podeis consultar en la sección de ezines de raona.

La sencillez de una interfaz compleja (versión e-zine).

Cada vez las aplicaciones son más y más complejas, y los usuarios son más y más exigentes. Los desarrolladores debemos afrontar este doble reto siendo capaces de proporcionar mejores y más complejas aplicaciones, en cada vez menos tiempo. Evidentemente este es un proceso global, que afecta a todo el desarrollo de una solución de software, pero me gustaría centrarme en los retos concretos que esto implica cuando hablamos de interfaces de usuario. No en vano, la interfaz de usuario es el punto de conexión entre el usuario y la aplicación. Es un elemento crítico y de su implementación depende en buena medida el éxito final de toda la aplicación.

Interfaces complejas

Las aplicaciones actuales demandan interfaces de usuario complejas a nivel técnico pero que a la vez sean sencillas de utilizar y de mantener. Que se adapten a cualquier tipo de usuario, que tanto usuarios expertos como inexpertos se sientan a gusto utilizándola. En resumen que la experiencia del usuario al utilizar la interfaz sea plena y que nuestra aplicación sea usable por cualquier usuario.

El término interfaz compleja, no quiere referirse al aspecto visual o usable si no al hecho de que cada vez es más complejo y difícil realizar interfaces que permitan conjugar las crecientes posibilidades de la aplicación con la sencillez de uso y la usabilidad. Este es el reto que debemos solucionar.

Nuevas tecnologías, nuevas posibilidades

Con la aparición de WPF, Microsoft ha dotado a los desarrolladores de un montón de nuevas posibilidades para la construcción de interfaces. El hecho de disponer de un lenguaje declarativo (XAML) para definir las interfaces permite la separación entre dos roles básicos hoy en día: los diseñadores y los desarrolladores. Pero separar desarrolladores y diseñadores es sólo un primer paso (un primer gran paso) pero no soluciona la problemática de fondo: el modo en cómo están diseñadas y desarrolladas las interfaces de usuario.

El mecanismo habitual de desarrollar interfaces de usuario en .NET, viene influenciado de los tiempos de Visual Basic. Es un patrón que consiste en una clase contenedora (llamada comúnmente formulario) que contiene a los controles y toda la lógica asociada a dichos controles. Por norma general el formulario se suscribe a los eventos de los controles a los que contiene y realiza la lógica apropiada en las funciones gestoras de dichos eventos. La ventaja de este modelo de programación es que es sencillo, intuitivo y fácil de aprender. Las desventajas son que al tener unidas la lógica con la presentación se vuelve más complejo el mantenimiento tendiendo a colapsar en grandes proyectos y se dificulta la separación del desarrollo entre varios equipos.

Una de las claves para desarrollar interfaces de usuario complejas y que resulten mantenibles es desacoplar la presentación de la lógica de dicha presentación. WPF presenta algunas novedades que ayudan a conseguir dicho desacople:

Commands: Permite desacoplar los eventos de los controles de la gestión de dichos eventos y unificar en un mismo punto la gestión de distintos eventos de distintos controles pero que realizan la misma acción (p.ej. un botón de una toolbar y una entrada de menú).
Routed Events: Permiten tratar en un solo contenedor cualquier evento generado por cualquier de los controles “hijos” (estén en el nivel de profundidad que estén).

Estas novedades aunque interesantes, por si solas no son suficientes para desacoplar totalmente la presentación y su lógica. Para ello hace falta un cambio de paradigma, un nuevo modelo.

Composite Application Library

Composite Application Library (CAL) también conocida por su nombre en código PRISM, es un framework lanzado por la gente de “Patterns & Practices” para ayudar en la construcción de aplicaciones complejas utilizando WPF.

CAL se basa en varios patrones para ayudar a conseguir un desacople total entre la presentación y la lógica de presentación. A continuación comentaremos tres de los patrones más relevantes de CAL.

Inversion of Control (IoC)

Este patron desacopla una clase en concreto de otra clase de las clases que utiliza, es decir de sus referencias:

La clase ClassA utiliza dos servicios (ServiceA y ServiceB) y por lo tanto tiene referencias directas a ellos. Esto implica, entre otras cosas, que si queremos modificar las referencias debemos modificar el código fuente de ClassA. Para desacoplar la clase de sus referencias la solución es añadir un componente externo que se encargue de encontrar y gestionar las referencias de la clase ClassA. En función de cómo diseñemos este elemento externo hablaremos de un patrón ServiceLocator o de Dependency Injection.

Con ServiceLocator la clase ClassA sólo contiene una referencia al Locator siendo esta clase la que obtiene y devuelve la referencia adecuada a la clase. El Locator NO instancia los servicios, simplemente los localiza (los servicios han estado instanciados previamente por alguien): mientras un servicio esté registrado, el Locator lo encontrará. CAL utiliza Unity para ofrecer un Service Locator, lo que nos permite instanciar y registrar servicios que luego serán utilizados en cualquier parte de la aplicación.

Con Dependency Injection, existe un Builder que crea el objeto del servicio y lo “incrusta” en alguna propiedad específica de la clase ClassA (o bien en algún parámetro del constructor). CAL utiliza Unity para proporcionar Dependency Injection.

Separated Presentation

Si IoC nos permite desacoplar nuestras clases de las referencias que necesitan, el conjunto de patrones conocidos como “separated presentation”, nos permiten separar la presentación de la parte de la lógica que gestiona la presentación.

Existen varios patrones que implementan “separated presentation” siendo los más concidos MVP (Model – View – Presenter) o MVVM (Model – View- ViewModel). Debido a las capacidades de WPF se tiende a utilizar más MVVM (mientras que MVP es más frecuente en aplicaciones Windows forms p.ej), debido a que MVVM se basa en uno de los aspectos más potentes de WPF: su data binding.

El patrón MVVM se basa en tres elementos:

Vista (View): Contiene los elementos visuales (controles). En el caso de WPF suele estar creada por un diseñador e implementada vía XAML
Modelo (Model): Contiene los datos que muestra la vista. En este punto es cuando se utiliza básicamente el data binding, para enlazar los valores de los controles de la vista a valores de distintos elementos del modelo.
Modelo de Vista (ViewModel): En interfaces sencillas, la vista se puede enlazar directamente con el modelo, pero en interfaces complejas no suele ser posible. En muchos casos el Modelo puede tener multitud de información que no se puede mapear a valores de los controles o bien nuestra vista debe realizar y mantener valores “temporales” que no forman parte estricta del modelo. Es en estos casos donde entra en escena el “ViewModel”, actuando de puente proporcionando transformadores para poder enlazar los controles de la vista y commands para que la vista pueda interactuar con el modelo.

De esta manera no existe más una clase “formulario” que contiene los controles y toda la lógica asociada a ellos.

Event Aggregator

Un Event Aggregator es la implementación de un modelo de eventos publish and subscribe, donde cuando alquien quiere recibir un evento se suscribe a este tipo de evento en particular. Cuando alguien quiere enviar un evento lo publica y el event aggregator se ocupa de que todos los que se hayan suscrito a este tipo de evento lo reciban. De esta manera se desacoplan totalmente los publicadores de eventos de sus suscriptores.

Conclusiones

Para desarrollar interfaces complejas que a la vez sean amigables para el usuario y mantenibles para el desarrollador es necesario involucrar a los diseñadores por un lado y desacoplar la presentación de la lógica que la gestiona por otro. Gracias a XAML, WPF permite que los diseñadores se integren totalmente en el ciclo de desarrollo, y el uso de determinados patrones permite desacoplar los distintos elementos que conforman la inferfaz de usuario. CAL es un framework y una guía de estilo que basándose en dichos patrones y en las funcionalidades inherentes a WPF nos permite desarrollar aplicaciones complejas que sean mantenibles y amigables a la vez.

Referencias

Command pattern in WPF (http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wpf_commandpattern.mspx)
Routed Events overview (http://msdn.microsoft.com/en-us/library/ms742806.aspx)
Model – View – Presenter pattern (http://msdn.microsoft.com/en-us/magazine/cc188690.aspx)
Model – View – ViewModel pattern (http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx)
Inversion of Control (http://msdn.microsoft.com/en-us/library/cc707904.aspx)
Service Locator Pattern (http://msdn.microsoft.com/en-us/library/cc707905.aspx)
Dependency Injection (http://msdn.microsoft.com/en-us/library/cc707845.aspx)
Dependency Injection on Martin Fowler’s site (http://www.martinfowler.com/articles/injection.html)
Event Aggregator (http://martinfowler.com/eaaDev/EventAggregator.html)
Event Aggregator (http://msdn.microsoft.com/en-us/library/cc707867.aspx)

Unity? Sí gracias, pero no me abraces demasiado…

Eduard Tomàs i Avellana — Mon, 02 Feb 2009 12:07:00 GMT

No hace mucho, Jorge Dieguez escribió un interesante post sobre Unity y el patrón de Dependency Injection. Resumiendo mucho este patrón permite eliminar las dependencias de nuestro código, trasladandolas todas a un sólo elemento, que se conoce generalmente como “contenedor de DI”. Este contenedor es el responsable de devolvernos todas las referencias a clases que nostros precisemos.

Las ventajas es que tenemos un código mucho menos acoplado, que por lo tanto es más fácil de probar y de mantener.

Contenedores de DI hay muchos, p.ej. en .NET tenemos a Unity (que viene de la mano de la gente de P&P) a Windsor Container o a Spring.NET sólo por citar tres ejemplos. Cada uno de ellos (y de los muchos otros que hay) tienen sus características y peculiaridades y dado que estamos pensando en hacer código débilmente acoplado… quizá deberíamos evitar ligarnos a nuestro contenedor DI, porque nunca sabemos cuando nos puede interesar cambiar.

Cojamos el caso de Unity. Imaginemos el siguiente proyecto super sencillo:

namespace UnityTest
{
    interface IFoo {}
    class FooClass : IFoo { }
    class Program
    {
        static void Main(string[] args)
        {
            UnityContainer uc = new UnityContainer();
            uc.RegisterType<IFoo, FooClass>();
            IFoo foo = uc.Resolve<IFoo>();
            Console.WriteLine(foo.GetType().FullName);
            Console.ReadLine();
        }
    }
}

Es una aplicación de consola, donde se declara una interfaz (IFoo), una clase que la implementa (FooClass) y luego en el método Main:

Se crea una instancia de Unity
Se registra el mapping entre IFoo y FooClass
Se obtiene una instancia de IFoo.
Miramos el tipo de la referencia obtenida

Como os podeis suponer lo que este programa muestra por pantalla es: UnityTest.FooClass

Unity nos devuelve una instancia de FooClass cada vez que le pedimos una instancia de IFoo, porque así lo especifica el mapping creado con RegisterType.

Hasta ahora todo perfecto: nuestra interfaz IFoo y nuestra clase FooClass no estan ligadas a Unity en ningún modo… vamos a ver como se nos pueden torcer las cosas…

Modificamos la clase FooClass para que tenga dos constructores:

class FooClass : IFoo 
{
    public FooClass() 
    { 
        Console.WriteLine("FooClass::Default ctor"); 
    }
    public FooClass(BarClass bar) 
    { 
        Console.WriteLine("FooClass::Bar ctor"); 
    }
}

El resto del código es igual que antes, con la excepción de que nos aparece una clase nueva (BarClass) que da igual (puede ser vacía, no nos afecta). La pregunta es obvia: ¿que constructor usará Unity para construir un objeto FooClass?

La respuesta es: el que tenga el mayor número de parámetros (¿la razón? Quien sabe…). Unity utilizará el constructor con mayor número de parámetros e inyectará todos los parámetros (llamando internamente al método Resolve) a dicho constructor. ¡Eh, un momento! Esto está muy bien pero… nosotros no hemos definido ningún mapping para BarClass en Unity… ¿No debería quejarse? Pues no: El método Resolve<T> de Unity es capaz de crear cualquier clase para que lo no haya un mapping definido, siempre y cuando T sea una clase, no una interfaz.

Si alguien se pregunta que pasaría si FooClass tuviese dos constructores con un parámetro, entonces Unity se quejará con una excepción parecida a: The type FooClass has multiple constructors of length 1. Unable to disambiguate.

Supongamos que queremos que Unity use un constructor en concreto (bien sea porque tenemos varios constructores con mayor número de parámetros o bien porque queremos usar alguno en concreto). En este caso, una solución es aplicar el atributo InjectionConstructor al constructor que queramos que use Unity:

class FooClass : IFoo 
{
    [InjectionConstructor]
    public FooClass() 
    { 
        Console.WriteLine("FooClass::Default ctor"); 
    }
    public FooClass(BarClass bar) 
    { 
        Console.WriteLine("FooClass::Bar ctor"); 
    }
}

Bueno… esto funciona correctamente, pero en este momento hemos creado una dependencia entre FooClass y Unity. Si algluna vez nos cambiamos a cualquier otro conenedor de DI, no podemos esperar que entienda el atributo InjectionConstructor, ya que éste, obviamente, es propio de Unity. Así que ahora nuestro código está acoplado a Unity… lo cual no es la solución ideal (en algunos casos).

Por suerte existe una solución que nos permite que nuestra clase FooClass no tenga dependencias contra Unity: cuando especificamos el mapping podemos indicarle que constructor utilizar. Para ello podemos usar el método Configure de Unity:

uc.RegisterType<IFoo, FooClass>().Configure<InjectedMembers>().
    ConfigureInjectionFor<FooClass>(new InjectionConstructor());

Aquí estamos registrando el mapping entre IFoo y FooClass, y configuramos los miembros inyectados para el tipo FooClass para que use el constructor sin parámetros. Si quisieramos usar el constructor con un parámetro BarClass:

uc.RegisterType<IFoo, FooClass>().Configure<InjectedMembers>().
    ConfigureInjectionFor<FooClass>(
    new InjectionConstructor(new BarClass()));

Con esto Unity cada vez que deba crear un FooClass, usará el constructor que acepta un parámetro BarClass y lo invocará con una instancia de BarClass. Unity usará siempre la misma instancia de BarClass para todos los FooClass que cree. Es decir, si tenemos:

IFoo foo = uc.Resolve<IFoo>();
IFoo foo2 = uc.Resolve<IFoo>();

Tanto foo como foo2 serán creados con el constructor que acepta un BarClass pero el BarClass que ambos reciban será el mismo. Incluso aunque no creemos ningún objeto FooClass, el objeto BarClass sí que se crea.

Si queremos que Unity cree cada vez un BarClass para cada FooClass, entonces podemos utilizar el siguiente código:

uc.RegisterType<IFoo, FooClass>().Configure<InjectedMembers>().
    ConfigureInjectionFor<FooClass>(
    new InjectionConstructor(typeof(BarClass)));

En este caso, Unity creará un BarClass nuevo cada vez que deba crear un FooClass… Bueno, esto no es estrictamente cierto: Realmente Unity cada vez llamará a su método Resolve<BarClass>, cada vez que deba obtener un BarClass para llamar al constructor de FooClass. Si no tenemos mapping definido, Resolve<BarClass> crea un BarClass nuevo cada vez. Pero, si definiesemos el siguiente mapping:

uc.RegisterInstance<BarClass>(new BarClass());

Aquí estamos registrando una instancia de BarClass como singleton dentro de Unity. Por lo tanto todas las llamadas a Resolve<BarClass> devolverán el mismo objeto… volvemos a la situación anterior: todos los constructores de FooClass recibirán el mismo BarClass. E igual que antes el BarClass se crea cuando se llama a RegisterInstance, por lo que aunque no creemos ningún FooClass, el BarClass sí que es creado.

Tenemos una variación de este caso. Si registramos BarClass como singleton, usando RegisterType:

uc.RegisterType<BarClass>(new ContainerControlledLifetimeManager());

Ahora BarClass está registrado como singleton, pero no se creará la primera instancia de BarClass hasta que sea necesario. Así, cuando creemos el primer FooClass, Unity creará el BarClass y lo usará como parámetro del constructor. Para crear el segundo FooClass, Unity usará el BarClass previamente creado.

Pero lo importante es que nuestra clase FooClass no depende para nada de Unity, de forma que podemos reutilizarla en cualquier otro proyecto o bien cambiar de contenedor de DI… Que sí, que Unity está muy bien pero tampoco es plan de que nos atemos a él, no????

Saludos!

IoC o el poder de ceder el control

Eduard Tomàs i Avellana — Tue, 28 Oct 2008 10:09:00 GMT

Hablando con colegas de profesión, me he dado cuenta de que muchos de ellos no terminan de comprender el patrón IoC o las ventajas que su uso comporta… Así que sin ánimo de sentar cátedra he decidido escribir este post, por si le sirve a alguien… J

IoC, que corresponde a las siglas de Inversion Of Control, agrupa a varios patrones que tienen en común que el flujo de ejecución del programa se invierte respecto a los métodos de programación tradicionales (wikipedia dixit). Generalmente el programador especifica las acciones (métodos) que se van llamando, pero en IoC lo que se especifican son las respuestas a determinados eventos o sucesos, dejando en manos de un elemento externo todas las acciones de control necesarias cuando lleguen estos sucesos.

Un claro ejemplo de IoC se encuentra en el modelo de eventos de Windows Forms. Cuando vinculamos una función gestora a un evento (p.ej. el Click de un Button), estamos definiendo la respuesta a un determinado evento y nos despreocupamos cuando se llamará a nuestra función gestora. Es decir, cedemos el control del flujo al framework para que sea él que llame cuando sea necesario a nuestro método.

Una de las principales ventajas de usar patrones IoC es que reducimos el acople entre una clase y las clases de las cuales depende, y eso cuando queremos utilizar por ejemplo tests unitarios es muy importante (no seré yo quien hable ahora de las ventajas de TDD cuando ya lo ha hecho Rodrigo (http://geeks.ms/blogs/rcorral/archive/2006/12/02/beneficios-y-carater-iacute-sticas-de-un-buen-test-unitario.aspx)). De los distintos patrones IoC me interesa comentar específicamente dos: Service Locator y cómo podemos usarlo en .NET. Para más adelante dejo Dependency Injection, otra forma de IoC que también es extremadamente útil.

Id a la nevera, coged una Voll-Damm o cualquier otra cervecilla y sentaos que este post es un poco largo… J

Service Locator

El objetivo de Service Locator es reducir las dependencias que tenga una clase. Imaginemos una clase, que depende de otras dos clases (p.ej. ServicioSeguridad y ServicioLogin). Podríamos tener un código tal como:

class Client

{

static void Main(string[] args)

{

new Client().Run();

}

private void Run()

{

// En este punto necesitamos objetos de las clases ServicioSeguridad y ServicioLogger

ServicioSeguridad ss = new ServicioSeguridad();

ServicioLogger sl = new ServicioLogger();

//...

}

En este punto tenemos un fuerte acople entre la clase Client y las clases ServicioSeguridad y ServicioLoggger. Seguiríamos teniendo este mismo acople incluso aunque utilizáramos interfaces porque deberíamos hacer el "new":

IServicioSeguridad ss = new ServicioSeguridad();

IServicioLogger sl = new ServicioLogger();

Las principales desventajas de esta situación son:

Las clases que implementan las dependencias (en nuestro caso ServicioSeguridad y ServicioLogger) deben estar disponibles en tiempo de compilación (no nos basta con tener solo las interfaces).
El fuerte acople de la clase con sus dependencias dificulta de sobremanera su testing. Si queremos utilizar Mocks para de ServicioSeguridad o ServicioLogger vamos a tener dificultades

El patrón de ServiceLocator soluciona estos dos puntos, sustituyendo las dependencias de la clase Client por dependencias a los interfaces y a un elemento externo, que llamaremos Contenedor encargado de devolver las referencias que se le piden.

Cuando la clase necesita un objeto en concreto, lo pide al contenedor:

IServicioSeguridad ss = container.Resolve<IServicioSeguridad>("servicioseguridad");

IServicioLogger sl = container.Resolve<IServicioLogger>("serviciologger");

El método Resolve devolvería una referencia del tipo especificado en el parámetro genérico de acuerdo con un identificador. Evidentemente falta alguien que cree el contenedor y que agregue los servicios a él. Es decir, en algún sitio habrá algo como:

container = new IoCContainer();

container.Add<IServicioSeguridad, ServicioSeguridad>(new ServicioSeguridad(), "servicioseguridad");

container.Add<IServicioLogger, ServicioLogger>(new ServicioLogger(), "serviciologger");

La gran diferencia es que esto no tiene porque estar en la clase Client. Simplemente pasándole a la clase Client una referencia al contenedor, eliminamos todas las dependencias de la clase Client con las clases que implementan los servicios. Y donde creamos el contendor? Pues depende… si estamos en nuestra aplicación, lo podemos crear en el método que inicialice la aplicación, pero si queremos probar la clase Client con tests unitarios podemos crear el contenedor en la inicialización del test…. Y lo que es mejor: rellenarlo con Mocks de los servicios!

Así, nuestro programa podría tener una clase Bootstrapper que crea el contenedor de IoC y lo inicializa con los objetos necesarios:

class Bootstrapper

{

static void Main(string[] args)

{

IIoCContainer container = new IoCContainer();

container.Add<IServicioSeguridad, ServicioSeguridad>(new ServicioSeguridad(), "servicioseguridad");

container.Add<IServicioLogger, ServicioLogger>(new ServicioLogger(), "serviciologger");

new Client(container).Run();

}

Pero si queremos usar tests unitarios de la clase Client, podemos cambiar los objetos por Mocks fácilmente:

[ClassInitialize]

public static void Init(TestContext context)

{

container = new IoCContainer();

container.Add<IServicioSeguridad, ServicioSeguridadMock>(new ServicioSeguridadMock(), "servicioseguridad");

container.Add<IServicioLogger, ServicioLoggerMock>(new ServicioLoggerMock(), "serviciologger");

}

[TestMethod]

public void TestMethod1()

{

Client c = new Client(container);

c.Run(); // Este método Run usará los Mocks!

}

Fijaos que podemos lanzar tests unitarios sobre la clase Client, sin necesidad alguna de cambiar su código y utilizando Mocks. Además, la clase Client no tiene ninguna dependencia con las implementaciones de los servicios que utiliza, así que no es necesario ni que existan para poder crear la clase Client (sólo necesitamos las interfaces).

Unity

Aunque existen varios contenedores IoC open source para .NET, Microsoft tiene el suyo, también open source, llamado Unity (http://www.codeplex.com/unity/). Unity proporciona soporte para los patrones Service Locator y Dependency Injection.

Para que veais un poco su uso he dejado un proyecto de herramienta de línea de comandos para listar los ficheros de un directorio (vamos un dir, jejejee…. J).

La solución está dividida en varios proyectos:

DemoIoC: Contiene el Bootstrapper, la clase que inicializa el contenedor de Unity, agrega la clase llamada ServicioFicheros y utiliza un objeto Cliente para realizar las acciones de la línea de comandos.
Cliente: Contiene la implementación de la clase Cliente.
Interfaces: Contiene las interfaces del servicio (en este caso sólo una)
Implementations: Contiene las implementaciones del servicio (en este caso sólo una)
Mocks: Contiene las implementaciones de los Mocks (en este caso sólo una)
UnitTests: Contiene tests sobre la clase Cliente, usando un Mock del servicio ServicioFicheros.

El ejecutable (proyecto DemoIoC, assembly DemoIoC.exe) es un archivo de línea de comandos que acepta dos parámetros:

DemoIoC –l para listar todos los ficheros (del directorio actual)

DemoIoC –e:fichero.ext Indica si el fichero "fichero.ext" existe (en el directorio actual).

Si lo ejecutáis veréis que NO funciona bien: lista los ficheros correctamente, pero devuelve que un fichero existe cuando no es cierto y viceversa. Si miráis el código de la clase Cliente, encontrareis el error, ya que es obvio, pero lo bueno es que el proyecto UnitTest, testea este método de la clase Cliente, usando un Mock del ServicioFicheros y el UnitTest detecta el error. Observad lo fácil que ha sido sustituir el ServicioFicheros por un Mock sin alterar la clase Cliente, gracias al uso del patrón Service Locator!

PD: Estooooo... que me he dejado de adjuntar el código de ejemplo... Lo teneis aquí!!!

Saludos!!!

Referencias

Os dejo algunas referencias para su lectura por si os interesa profundizar un poco en el tema tratado:

Unity Container (http://www.codeplex.com/unity/)
Patrón Service Locator (http://msdn.microsoft.com/en-us/library/cc707905.aspx)
Inversion of Control (http://msdn.microsoft.com/en-us/magazine/cc947917.aspx)
Mocks (http://martinfowler.com/articles/mocksArentStubs.html)