Castle.Windsor Fluent Registration API

Ya vimos en un post anterior como podemos configurar el container de Castle con Fluent Registration API al igual que con xml. Ahora vamos a ver algunas cosas que podemos hacer con Fluent donde, quizás, empiece a sacar ventaja. Espero que el siguiente código sea suficientemente claro.

Creamos nuestro container

IWindsorContainer container = new WindsorContainer();

Registramos todos los DAOs

container.Register(
AllTypes.Of<IDAO>()
.From(typeof(InvoiceDAO).Assembly.GetTypes())
.WithService.FromInterface()
.Configure(cr => cr.LifeStyle.Singleton));

“registramos en el container” (línea 1), “todos los types que implementan IDAO” (línea 2), “del assembly al que pertenece InvoiceDAO (en este caso DMS.DAOs.NH” (línea 3), “como servicio tomamos la interface que implementan” (línea 4) y “los configuramos como singleton” (línea 5).

Registramos todos los models

container.Register(
AllTypes.Of<IModel>()
.From(typeof (InvoiceViewModel).Assembly.GetTypes())
.WithService.FromInterface());

creo que ya no hace falta “leerles” lo que dice el código. La diferencia con la registración de los DAOs es que en este caso registramos todas las implementaciones de IModel en el assembly DMS.Models.Impl.

Registramos todos los services

container.Register(
AllTypes.Of<IService>()
.From(typeof(InvoiceService).Assembly.GetTypes())
.WithService.FromInterface()
.Configure(cr => cr.Interceptors<SessionInterceptor>()));

Igual que antes, salvo por que les configuramos el interceptor (SessionInterceptor).

Conclusión

Por si no quedó claro, la ventaja que intento mostrarles es que no necesitamos declarar cada componente (existente o que existirá), sino que con esta configuración y si seguimos implementando las interfaces correspondientes (IDAO, IModel e IService) automáticamente se agregarán al container y se inyectaran las dependencias.