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.
