Looking for Builder Advice

Nov 2, 2006 at 5:25 AM
I have been using the DI Container example that Brad provided at the P&P summit last month. It has been very helpful. During that time I haven't been able to figure out a good way to support session-type objects. These are basically objects that are unique in some context. It would be nice to use objectbuilder to create these and I could just create a DependencyContainer and store it in a call context. The drawback is that I need a

I took a look at the Singleton Strategy and it is pretty close to what I want but not quite. It looks possible to modify the Singleton behavior to recoginize the ID property of the key or create a new NamedSingleton Strategy.

Another alternative might be to use a different LifetimeContainer for each context. Does it seem possible that this could be stored in some CallContext?

The last option is to create a new ObjectBuilder for each Session. This is the approach I have taken but it seems like there is a lot of work going on just to have named Singletons. I am creating them with a Guid key on CallContext.

Do any of these make sense or is ObjectBuilder or the example DI container the wrong tool for this type of situation?

Thanks,

David Morris
Nov 3, 2006 at 4:34 AM
I think if I was making a DI container for web apps with session type system, I would probably write support for hierarchical containers, and for each session, new up a new container that uses the app-wide container as its parent.

If you need the container to decide based on type which things are per-session and which are app-wide without getting the client code involved, then you could modify the creation strategy to take some policy which says in which container an object gets created.

Just a thought off the top of my head...
Nov 3, 2006 at 6:12 AM
I guess you are thinking that it would be reasonable to create a new hierarchical container that implements ILifetimeContainer and use it in the DependencyContainer class. The Hierarchy is pretty flat with app wide and session scoped objects. It seems possible that it would be useful to nest sessions but that isn't an immediate requirement. I took a quick scan of the .NET Framework Class library and something similar to IHierarchicalEnumerable seems like a good candidate. Would you just call dispose on the container when the session dies?

I can see where the creation strategy needs to recognizes the hierarchy -- would the same apply to the locator?. It looks like the locator maintains it's own dictionary and contains a reference to the container. Why does the locator need to know about the container?

Thanks for the help,

David Morris
Nov 10, 2006 at 5:09 PM
Hi Brad,

Based on your input I have something that is working. I created a class with a reference to the builder, a nested locator and a nested lifetime container. I added a reference to the root container's locator with the session key. I found I had to have the builder to support dispose and a locator that pointed to the container.

I had to put the nested container into the root container so that it woudn't get GC'd. That makes it necessary to search for and remove the nested container from the root container on session dispose. Instead, I could have put a reference to the session into its nested container but that would require passing a session reference when the container is created -- not sure which is better.

Does this seem like a reasonable approach?

Thanks,

David Morris