As a brief follow up to my
last post here I thought I'd quickly post about something I've been doing lately with my own
windsor configurations, which is pretty minor - but saves me a little grief when it comes to refactoring etc.
Basically I have this extension method:
public static ComponentRegistration<S> RegisterTransient<S>(this IWindsorContainer container, ComponentRegistration<S> registration)
{
container.Register(registration.LifeStyle.Transient);
return registration;
}
Which then lets me do this:
var serviceA = container.RegisterTransient(Component.For<IStaffRepository>()
.ImplementedBy<StaffRepositoryA>());
var serviceB = container.RegisterTransient(Component.For<IStaffRepository>()
.ImplementedBy<StaffRepositoryB>());
container.Register(Component.For<IStaffService>().Named("service.staff").ImplementedBy<StaffService>()
.ServiceOverrides(ServiceOverride.ForKey("Repositories").Eq(serviceB.Name, serviceA.Name)));
var staffService = (StaffService)container.Resolve<IStaffService>();
Assert.IsType<StaffRepositoryB>(staffService.Repositories[0]);
Assert.IsType<StaffRepositoryA>(staffService.Repositories[1]);
notice the lack of strings when registering service overrides... it's a minor thing, but I find it quite handy... plus it generally makes it easier to identify the lifestyle of the components being registered because it's a little more in your face, i.e. your making an explicit decision... though anywhere that lifestyle poses a risk you should obviously be writing some unit tests to verify your getting the expected behavior when resolving that service anyway.
Also, while looking at ComponentRegistration<S> -the other nice thing about the fluent component registration is it works quite well for add-ons that introduce their own services which aren't loaded into a seperate app domain or child kernel ...
Just give the add-in an installation "helper" which only exposes a method taking a ComponentRegistration<S> for registering the component... you can then defer when those services are actually registered in the kernel, and can use the names of the components or other info to unregister them if the add-in is turned off (obviously this is a rainy day scenario and there are problems with this approach, but so far I've found it to work quite well).