For #1 yes, context is tracked per user session. Turns out that what you’re asking for on #2 is possible with this framework (I’ll be covering areas like this in the next post, and I’ll post a comment afterward explaining how it applies to your scenario).

What I’m thinking about is something which addresses the need that I think the httpSessionStore is trying to achive (i.e. providing different context values depending on the active user or other varying context). I assume that your httpSessionStore returns different values based on the active session. What I was asking was for was actually using different context stores of the same type with the same container (or with multiple containers which use the same registration catalog).

The way that I implemented this is that I have a root container which has no context and where everything is registered. Later when a context is created a child container is created from the root container using the given context. This child container inherits the registrations from the root container. Once the child container is created its context cannot be changed (although I probably could allow changing the context with a little work).

For #2 I started to write a scenario and then I realized that what I’m asking goes beyond what you’re trying to do. I think that what I’m looking for is simply to specify a factory to build the object and for the container (and context store) to be passed to the factory so that the factory can utilize the container to build the required object.

Thanks for your response. I think that what you’re trying to do is something many people would like.

If I were to do a Per-Request, Per-Session, Per-Instance model, with three context stores (for example), would I predetermined a precedence for how I check? Would it be RequestContext before SessionContext before ApplicationContext? Would that force a user into a specific model (something I don’t want to do).

Or could I allow users to add more than one context store? If I do that, do I need to allow users to specify a precedence between them? How do I make sure the correct store is looked at first for resolutions if multiple contexts are able to satisfy a use case, but they ultimately resolve to different types?

Those are the questions I’ve been debating. So in the end I’ve settled that until a better way is pointed out, I’ll put the burden on the consumer to define an implementation of IContextStore that satisfies their needs. Maybe someone will create a ComplexContextStore that has an internal list of IContextStores for different scopes, and can it determine how to return its items in the correct fashion to the SiegeContainer. I dunno. I’m open to ideas.

For #2… I hadn’t really considered that idea. Right now I suspect an object has to exist in context for it to be evaluated. I agree that it is more robust, but what I’m curious to see is a scenario where you’d do this. That will help me understand better what the goal is behind it.

1) Is there a way to use different context store objects with a single container or is there a way to share registrations between containers?

I have found that it is very useful to be able to perform all of the registrations once and then use those common registrations under different contexts at the same time (in my case I create multiple containers each with its own context and each using a single shared registration).

For instance on a web server which is receiving multiple requests from different users you want to resolve using different contexts for each request but you don’t want to have to re-register everything for each request.

2) In the “When” part of the registration can only objects which are part of the context store be resolved or are the resolved objects registered with the container itself?

For instance, in your example where you are getting VendorStatus, must VendorStatus be an object in the context store or can it be any object which is retrieved from the container? I think that being able to make a decision based on an object in the container is more robust than limiting decisions to items in the context store alone.

The reason for a UnitContainerAdapter is simple, most firms have the firm belief that if it’s from Microsoft than it is better than anything else. So as a developer you won’t be able to propose the use of X or Y unless it’s from Microsoft.