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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
