I Guess a child container concept as in how it will work in 3.0 would resolve (haha) all my problems. Don't have in depth knowledge of how other containers could solve contextual dependencies, so I will have a look, maybe there are some clever solutions that could inspire the subcontainer redesign in 3.0.....
2010/9/21 John Gunnarsson <[email protected]> > Today a realm is a composition of a container, realm specific configuration > (connection strings etc) and a realmid. > > There is a world concept aswell, simply containing a list of all realms. > The world also has a container, containing services etc. > From the world I can locate a realm by realmid. > > rest requests is not the only way of starting a rootservice resolve, > we got windows services that could be targeted to perform some task > (aggregate data from a rdbms to a mongo instance for examle) for a specific > realm (resort), where the reamid could come from a config file. > > > > > > 2010/9/21 Krzysztof Koźmic <[email protected]> > >> ok, let's step back a little. >> How do you use the realm id and the container exactly? >> >> >> On 21/09/2010 7:19 PM, John Gunnarsson wrote: >> >> Well, for the cases where everyting starts with a request, that would be a >> viable solution. >> >> But for the other cases where we rather perform something on each realm >> (and aggregate the result from each realm), the request cannot be the thing >> used to determine the contex.... >> >> >> >> 2010/9/21 Krzysztof Koźmic <[email protected]> >> >>> OK, >>> >>> I'm guessing you could use handlerselectors for this. >>> Since as you mentioned the id is passed in the request you can get access >>> to the current request in the selector and get the id and perform the >>> selection logic there. >>> >>> thoughts? >>> >>> Krzysztof >>> >>> >>> On 21/09/2010 7:06 PM, John Gunnarsson wrote: >>> >>> The site is a portal for several resorts. >>> Each resort has it's own database and other specific resources. >>> >>> As a user you could either search for available available accomodation in >>> one resort, >>> or you could search for available accomodation for all resorts. >>> >>> So, requests can be realm (resort) specific, where we got a realmId (that >>> comes as a rest req. param) that determines in which >>> realm to resolve a specific component. (today we locate the realm for the >>> realmId, and uses it's ioc container to resolve all realmspecific stuff) >>> >>> For the situation where we would like to invoke same logic for several >>> realms, (aggregate all available accommodation for all realms into one >>> search result) >>> we simply loop all realms and perform some action on each realm where the >>> action will get the correct dependencies injected into them via the realm. >>> >>> Ehh, well, hope I have clarified something, or did I make it worse? :) >>> It's kind if a special case, we are integrating with an existing system. >>> >>> >>> >>> >>> >>> 2010/9/21 Krzysztof Koźmic <[email protected]> >>> >>>> There's no way to pass any parameters to handlerselectors. >>>> What are these realm things? How do you decide what realm you're in at >>>> any given point in time? >>>> >>>> >>>> On 21/09/2010 5:05 PM, John Gunnarsson wrote: >>>> >>>>> Okay, >>>>> >>>>> Well its almost like a multi tenancy situation. In some situations the >>>>> application Will handle operations on several realms, so i cant rely >>>>> on one thread = same realm or something like that. >>>>> >>>>> So how do i provide the context? Can i pass some kind of context at >>>>> resolvetime that the IHandlerSelector can use for its decition? >>>>> >>>>> >>>>> >>>>> On Tuesday, September 21, 2010, Krzysztof Koźmic >>>>> <[email protected]> wrote: >>>>> >>>>>> From what I understand what you call realm is usually called a >>>>>> tenant. >>>>>> >>>>>> In general Windsor's solution for multi tenancy is to have one >>>>>> container with all the components (that would mean you'd register all >>>>>> your >>>>>> ISessionFactories) and then use IHandlerSelector to pick the one that is >>>>>> needed. >>>>>> >>>>>> 2010/9/21 quo<[email protected]> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I would like some advice from you guys regarding contextual >>>>>> dependencies >>>>>> >>>>>> So my case looks like this, I got a bunch on components registered in >>>>>> my container (transients) >>>>>> In the applicaton i got something that I call realms. Each realm got >>>>>> it's own database (nhibernate ISessionFactory), a mongo session >>>>>> factory etc. etc. >>>>>> >>>>>> Usually i want to resolve a component within the context of a realm, >>>>>> so for example, I expect to have the correct session factory injecten >>>>>> into my repositories etc. >>>>>> >>>>>> The solution that I have today is to have one Ioc container for each >>>>>> realm, and register all transients in every realms container, >>>>>> additionally to register diffrent singelton instances of the >>>>>> sessionfactory etc in each realm. >>>>>> >>>>>> My prefered solution would be something like having one container to >>>>>> register all my transients in (all common components, only registered >>>>>> once), and depending on my context somehow provide additional >>>>>> dependencies like sessionfactory etc. >>>>>> >>>>>> Initially a childcontainer per realm (to be used as a context where I >>>>>> could register sessionfactories etc) seemed like my new best friend, >>>>>> but unfortunately that didn't work out: >>>>>> http://issues.castleproject.org/issue/IOC-116 >>>>>> >>>>>> My next try was do provide my contextual dependencies via a >>>>>> Dictionary<Type,object> at resolve time, but that didn't work either: >>>>>> http://issues.castleproject.org/issue/IOC-219 >>>>>> >>>>>> >>>>>> My design goal is that my components should not be aware that there >>>>>> exists several realms, they should just depend on the fact that all >>>>>> underlying dependencies is correctly resolved. >>>>>> >>>>>> How do you solve contextual dependencies? >>>>>> Can't find any good info about someone else having the same >>>>>> requirement's, have I screwed up royal in my design? >>>>>> >>>>>> >>>>>> //John >>>>>> >>>>>> -- >>>>>> 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]<castle-project-users%[email protected]> >>>>>> . >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/castle-project-users?hl=en. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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]<castle-project-users%[email protected]> >>>>>> . >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/castle-project-users?hl=en. >>>>>> >>>>>> >>>> -- >>>> 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]<castle-project-users%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/castle-project-users?hl=en. >>>> >>>> >>> -- >>> 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. >>> >>> >>> -- >>> 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]<castle-project-users%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/castle-project-users?hl=en. >>> >> >> -- >> 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. >> >> >> -- >> 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]<castle-project-users%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/castle-project-users?hl=en. >> > > -- 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.
