Using a short-lived form objects with StructureMap

Question

I have this application I'm writing and it's become a bit of a disaster in terms of organization due to the size of it. I figured this would be an ideal candidate for implementing IoC using StructureMap v3.1.4.143.

I'm setting up my object graph in my Program.cs and creating an application context that takes a few dependencies in its constructor. One of those is a splash screen form. When the app context runs, it displays this form, and updates the current status on the form depending on what's happening at initialization.

This object is quite temporary, and once I dispose it, what does StructureMap do with it? Does it cache the object in some fashion? It seems kind of wasteful to leave the object rooted and disposed if indeed it's cached in some fashion. Should I use a nested container for it? I'm trying to avoid passing containers around if I can manage it, and the app context must dispose of this object as it calls Application.Run (which is modal). So is there a good way to handle this situation? I really don't want to leave objects just hanging around, unreachable by the GC when they're no longer used.

This leads to another design issue that will likely come up: If I click a button, and a new form is created, worked with, and disposed, how would I handle this via StructureMap? I need to create the form at runtime, and only on demand. And I don't want to keep it around after the user is done with it (I consider it wasteful). If I dispose of the form, and create a new instance using a factory method injected by StructureMap, will it return the previous instance in a disposed state?

And just to get this out of the way now: "hiding" it on form close is not an option here.

This is really a different way of thinking that I'm certainly not used to. So any guidance would be greatly appreciated.

Answer 1

As a preface I'd like to say that I don't have any experience with Forms I'm unsure how Forms handles IoC container integration - so I'm not sure exactly how useful this answer may be; however it does sound like the solution to this problem is to use StructureMap's Nested Container feature.

An extract from the documentation:

Nested Container's are a powerful feature in StructureMap for service resolution and clean object disposal in the context of short lived operations. Nested Container's were introduced in version 2.6, but greatly improved in both performance (100X reduction in the time to create a nested container in a large application) and ahem lifecycle mechanics as a major goal of the 3.0 release.

Using a Nested Container you're able to take what's essentially a clone of your configured container that's suitable for short lived operations. Any changes to the nested container are not reflected in the container that it's created from.

Creating a nested container is easy enough and can be performed by calling the GetNestedContainer() method on your IContainer instance; here's an example:

IContainer container = new Container();
container.Configure(c =>
{
    c.IncludeRegistry<ConfigurationRegistry>();
});

IContainer myNestedContainer = container.GetNestedContainer();
myNestedContainer.Dispose();

As you see from the example, the nested container implements the IDisposable interface so you can manually dispose of the container once you're finished with it.