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 -~----------~----~----~----~------~----~------~--~---
