Castle MicroKernel is not intuitive for the SmartClient/CAB developers
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.
No comments yet.
Leave a comment
Search
Archives
Recent Comments
- aCoder on Extension methods for interfaces
- Requirements for the Photon .NET project | Rinat Abdullin on IRepository, cross-cutting concerns and flexibility
- Nicholas Blumhardt on Extension methods for interfaces
- aCoder on IRepository, cross-cutting concerns and flexibility
- Rinat Abdullin on Blog upgraded
- Rinat Abdullin on Extension methods for interfaces
- IRepository, cross-cutting concerns and flexibility | Rinat Abdullin on Extension methods for interfaces
- Bill Pierce on Blog upgraded
- aCoder on Extension methods for interfaces