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]
<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].
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].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
