How best to implement a Per-View Life-Cycle for IoC Injected Components

I am working on a WPF application using an MVC architecture and an IOC Container. Presently, I am wrestling with a design issue involving the scope and lifetime of certain container provided components. Here is the situation.

I will generalize by saying somewhat incorrectly that IOC containers support two component life cycles, singleton and transient. But what we need is a middle ground for certain sets of components.

Consider a view which displays a list of records in a grid. When the user clicks on a record, a new view opens to display record details and allow editing. The user can have many such views open, each displaying a different record. Each view gets its own model and controller as well.

Within the context of a given model-view-controller set, there are some components such as dialogs that are both transient and lazily injected. That is to say we want a new instance each time we need to display one and since most of these transients are only needed if the user takes certain action, we initially only inject a factory delegate. The delegate is then invoked as needed to perform the actual dependency resolution.

Beyond the model, view and controller, there are a host of other components for which we want one instance per m-v-c set. For example, we are implementing the NHibernate conversation pattern that calls for a session to be opened when the view opens and remain open until it closes. Likewise, each set needs its own shared event broker and potentially a few "other things." If all these dependencies were resolved at the moment the view was created, this would not be a problem. We could declare all of them as transient and be done with it.

However, some of those lazily resolved dependencies themselves have dependencies on the model, the controller or the "other things." So the problem is, when resolving a lazy dependency, the container behind the delegate needs to inject the right instance of each dependency. This of course implies that the delegate itself is somehow tied to the m-v-c set, but that should not be an issue if the larger problem can be resolved.

Now above I said that I was oversimplifying the list of supported life cycles. Most containers support some intermediate life cycles such a per-thread or pre-request, which allow scoping that is conceptually similar to what we are looking for. These do not apply in a interactive UI scenario though. It is not the case that each view is on its own thread or in some other convenient context that provides the basis for scoping.

Thus my ques开发者_如何学Pythontion is, what is the best way to implement a per-view (or per any arbitrary context) component life cycle using an IOC container. Our present container is Unity but we have abstracted ourselves well enough that we could switch without too much difficulty. So if this is more readily implemented in, or is implemented out of the box by another container, we could consider switching.

---

The pattern you describe is the unit of work. You are correct in that it is easily defined for web requests, but incorrect in stating that it does not apply to interactive UI scenarios. The view itself is the context for scoping - you know when you move to it and away from it, and those are the points at which you respectively create and destroy child containers:

1. Move to view
2. Create child container for view
3. Resolve view instance from child container
4. Do work
5. Destroy child container
6. Move away from view