I’ve just finished porting current xLim 2 implementation from WindsorContainer to autofac.
It took about 14 hours total to have this out of my way (this also included adding C# 3.5 features to all 20 projects in the primary solution while keeping the output .NET 2.0 compatible).
Disadvantages:
- Configuration files got clumsier. Autofac does not support includes and property aliases, yet.
- When we had Castle I didn’t see the possibility to cleanup the logical organization of xLim solutions at business/configuration level. Now I do see that. It hurts to see the improvement that’s not feasible at the moment.
Benefits:
- We had to use modified Castle sources in order to be able to run xLim under medium trust level of some hosting providers (minus one point for the maintainability). Autofac just works.
- 5 Castle assemblies were replaced by 1 small autofac library. Getting rid of extra code is efficient.
- We had to manually copy transient ComponentModels from the upper scope to the child scope (or register them manually) to keep the resolution bound to the current context. This code was also gone, since Autofac inherently supports multiscoping.
- There’s greater flexibility in controlling lifecycle of views, commands and workflows. This will be utilized.
On the overall - Castle is a great solution, but autofac is a better tool for the specific purpose of building xLim 2.
0 Responses to “Experience of migrating from Castle to autofac”