Menu
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 question 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.
831
The IoC container constructs an object of the selected class and also injects all the dependency objects via a constructor, a property, or a function at execution time and disposes it at a suitable time. This approach helps to create and manage objects manually.
ASP.NET Core contains a built-in dependency injection mechanism. In the Startup. cs file, there is a method called ConfigureServices which registers all application services in the IServiceCollection parameter. The collection is managed by the Microsoft.
A DI Container is a framework to create dependencies and inject them automatically when required. It automatically creates objects based on the request and injects them when required. DI Container helps us to manage dependencies within the application in a simple and easy way.
This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies by using direct construction of classes, or a mechanism such as the Service Locator pattern.
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:
131
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
