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.