Ok, now it is official. The father of Autofac .NET IoC Container, Nicholas Blumhardt, has joined the team of Krzysztof Cwalina at Microsoft.
He will be the Program Manager in a team that’s building the Managed Extensibility Framework
Additionally Hamilton Verissimo (founder of the Castle project) will be joining the same team.
Congratulations and good luck, Nick! You can make the difference out there))
PS: Nick and Hamilton will still be able to spend as much time as they want on their pet projects. There’s the permission from Microsoft for that.
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.
Imagine the following situation: we have two containers that are linked together in child-parent relationship. Child knows about the parent and can lookup components in it.
The following operations are valid in Castle MicroKernel:
- Child.Resolve<SecurityContext>()
- Child.Resolve<WorkflowContext>()
- Child.Resolve<DataAccessLayer>()
- Child.Resolve<WorkflowController>()
But if the WorkflowController depends on "WorkflowContext" and "SecurityContext", then the last resolution statement will result in failure. That is weird… we initiate dependency resolution for the transient component in the child container, so logically we should have access to both the child and the parent.
This makes Castle kernel hierarchy non-intuitive for those who plan to implement ideas from the Smart Client/CAB in their applications.
xLim 2 architecture hit this limitation in all the session-specific scopes for the web UI, desktop editor contexts, injection of the workflow micro-controllers into the Views. The simplest solution is to manually tranfer all the required transient ComponentModels from the parent container to the child, when it is created.
March 03, 2008: autofac IoC project does not have this limitation. It is amazing what one could do with the proper scope and lifecycle support and new C# syntax.
Latest Comments