We have applications with a plug-in style architecture. The
application itself is divided into several "execution contexts". Each
"execution context" hosts a subset of the available plug-ins, and the
same plug-in (but different instances) can be hosted by several
"execution contexts" simultaneously. Also, each plug-in offers
multiple "usage scenarios". Keeping all that in mind we have 4 scopes
for the components we register:
1. Common or "framework" scope: components registered in a root
container available to all "execution contexts" and every "usage
scenario" of their plug-ins.
2. Context-specific scope: components registered in an "execution-
context" specific container (a child of the root container) available
only to that context and every "usage scenario" of its plug-ins.
3. Plug-in-specific scope: components registered in a plug-in specific
container (a child of a given context-specific container) available
only to that plug-in and its "usage scenarios".
4. Scenario-specific scope: components registered in a "usage
scenario" specific container (a child of a given plug-in specific
container) available only to that "usage scenario".
Each of these 4 scopes has the option of using TypedFactories to
perform "runtime" type resolution.
The problem we're facing concerns the use of TypedFactories by any of
the sub-containers (scopes 2-4 above). We would expect that when using
a TypedFactory in a given sub-container, that TypedFactory would use
its associated sub-container to perform any resolution, not the root
container (scope 1)! It should not matter that a parent container has
also added the TypedFactoryFacility.
In the simple sample I provided, the TypedFactory, IFooFactory, that
was registered on childContainer, was only able to resolve the type
IFoo from childContainer if mainContainer had not also added the
TypedFactoryFacility:
IWindsorContainer mainContainer = new WindsorContainer();
IWindsorContainer childContainer = new WindsorContainer();
mainContainer.AddChildContainer(childContainer);
//mainContainer.AddFacility<TypedFactoryFacility>();
<--- uncomment this line to make the test fail.
childContainer.AddFacility<TypedFactoryFacility>();
childContainer.Register(Component.For<IFooFactory>().AsFactory());
childContainer.Register(Component.For<IFoo>().ImplementedBy<Foo>());
var test = childContainer.Resolve<IFooFactory>();
var facility = childContainer.Kernel.GetFacilities()[0];
var test2 = test.CreateFoo();
Version 2.1.1 supported this functionality, but it seems to have been
broken/changed in version 2.5. What would be the point of adding a
TypedFactoryFacility to a sub-container that can only resolve types of
its parent container and not its own types? IMHO, None.
Wouldn't it be more logical/natural to assume that any
TypedFactoryFacility added to a sub-container should be used to
resolve types from that sub-container (and its parent)?
On Aug 24, 5:56 pm, Krzysztof Koźmic <[email protected]>
wrote:
> How are you using the facility? What do you use sub container for?
>
> sent from my HTC Desire
>
> On 25/08/2010 12:48 AM, "Eric Martin" <[email protected]> wrote:
>
> Thanks for the quick response
>
> I have tried the solution you propose and it worked, but it brings another
> question to me.
> What is the best way to use Typed Factories in the case of sub container?
> Adding a TypedFactoryFacility to a subcontainer is a bit useless (unless
> relying on a sequence when adding/registering) because the interceptor will
> always be the one of the first facility added.
> The previous implementation seems a bit more natural to me. If I want to use
> a typed factory in a subContainer, then I am able to add a new facility to
> this container and when resolving something using this facility, I know I
> will look in the right container.
>
>
>
> On Tue, Aug 24, 2010 at 9:36 AM, Eric Martin <[email protected]> wrote:
>
> > Hi
>
> > The follow...
--
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
