Disposable Instances Series
In the past few weeks I have published a set of four posts that deal with disposable instances. These posts describe in detail a working implementation that automatically disposes all the instances that are no longer needed, in a deterministic way. This solution works when we use Dependency Injection or Service Locator to create instances and we want to prevent, by design, leaks of expensive resources.
The posts started from a discussion on how to deal with a repository implementation, which is disposable by nature, and it evolved into a broader one, because the same challenges and approaches apply to any disposable type.
Even if I didn’t intend them from the beginning to be a series, these posts continue each other and describe the design of a component that may be part of the Application Software Infrastructure of any complex app. They include the problem description, the challenges, the different approaches which may be considered and implementation examples.
The posts are:
- Who Disposes Your Repository – where I describe the context and the challenges of dealing with a disposable Repository and Dependency Injection. In this post I also compare different alternatives of handling the dispose in a repository implementation
- Extending Unity Container for IDisposable Instances (1st approach) – here I detail the challenges of achieving automatic dispose with Unity Container and I describe one implementation approach with its pros and cons
- Extending Unity Container for IDisposable Instances (2nd approach) – here I continue the post above with another solution for extending Unity with this behavior. This implementation overcomes the shortcomings of the previous one, but raises some design concerns
- Disposing Instances when Using Inversion of Control – here I complete the solution by addressing the question of when the disposables are going to be disposed. I give a solution for defining a scope for any operation in any kind of app in a similar way as we have the Request in an web app