IHandlerSelector or ISubDependencyResolver are the two common ways to handle that You can also look at INamingSubsystem, I think there is another impl that already does much of that.
On Wed, Aug 5, 2009 at 11:31 PM, sbohlen <[email protected]> wrote: > > Replying to my own Q with some reference materials... > > The only viable answer I was able to identify is the IHandlerSelector > extension point which, while working fine, seems inelegant for the > large number of object constructions that I will need to process/ > handle. Unless someone comes up with a better choice, I'm going to > proceed with IHandlerSelector. > > Some reference materials... > > HandlerSelectorsTestCase.cs in the Castle Windsor test unit tests > at ...\InversionOfControl\Castle.Windsor.Tests\... (Castle's unit > tests never seem to fail me as the best way to reverse-engineer how to > use a feature) > > The always helpful if somewhat terse posts from Ayende... > http://ayende.com/Blog/archive/2008/10/05/windsor-ihandlerselector.aspx > > This Stack Overflow answer (which also offers an example > implementation) > > http://stackoverflow.com/questions/313796/multiple-interface-injection-with-castle-windsor > > If anyone wants to offer a more elegant solution to my issue than one > or more IHandlerSelector implementations registered with the > container, I'm still open to suggestions~! > > -Steve B. > > On Aug 5, 2:20 pm, sbohlen <[email protected]> wrote: > > I'm looking for any recommendations as to the best pattern to > > accomplish a sort of meta-data-driven resolution of service 'groups' > > using WinsorContainer. > > > > Let's say I have multiple instances of each implementation registered > > with the container, each one given a service id that in some way > > associates it with the 'group'. For instance, imagine the following: > > > > type: IServiceInterface1 > > service: TheTopService > > id: "customer1.service1" > > > > type: IServiceInterface2 > > service: TheDependentService > > id: "customer1.service2" > > > > type IServiceInterface1 > > service: AnotherService > > id: "customer2.service1" > > > > In some cases, I need the hierarchy of objects resolved from the > > container with keys prefixed with "customer1" and in other cases I > > need the hierarchy of objects resolved from the container with key > > prefixed with "customer2". > > > > Obviously I can always ask the container for the service by its > > explicit id as in... > > > > IServiceInterface1 theService = > > container.Resolve<IServiceInternface1>("customer1.service1"); > > > > ...and... > > > > IServiceInterface1 theService = > > container.Resolve<IServiceInternface1>("customer2.service1"); > > > > ...but at run-time, I'd rather the code asking the container to > > perform the resolution NOT have any awareness of having to ask things > > by service id. This gets exponentially more complex because even were > > I willing to accept the use of the id value at the initial call to > > Resolve<T>, I would still need to start registering specific service > > overrides for all of the dependencies that the parent objects in turn > > have for themselves. > > > > Basically, in a nutshell I have the need to register mutiple parallel > > hierarchies of objects with the container and then (in the simplest > > manner possible) have the container return either one entire object > > hierarchy or another based on some discriminator strategy. > > > > I'm curious whether anyone has any experience with this kind of an > > approach...would I be better off simply using a completely separate > > WindsorContainer instance for each of the separate discriminators I > > expect (e.g., one container for objects for 'client1', another for > > objects for 'client2', etc. in my above example)? > > > > Recommendations as to the cleanest way to attack this would be > > welcome. > > > > Thanks in advance, > > > > -Steve B. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
