Question

My Controllers inherit from a class that contains a field that implements IDisposable. So my first instinct was to write:

public abstract class EventRepositoryControllerBase : Controller
{
    protected EventRepository eventRepos { get; private set; }

    public EventRepositoryControllerBase(EventRepository eventRepos)
    {
        this.eventRepos = eventRepos;
    }

    public override void Dispose()
    {
        try
        {
            base.Dispose();
        }
        finally
        {
            eventRepos.Dispose();
        }
    }
}

but this won’t compile because Controller does not mark the Dispose method as virtual/override. So now I think I’m stuck. Even if I mark my method as new, won’t the framework hold references typed as Controller and as such my method will never be invoked? Suggestions on how to work around this?

UPDATE

So I looked at the MVC3 source and saw this:

 public void Dispose() {
        Dispose(true /* disposing */);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing) {
    }

So I guess I’ll just put my code in the 2nd method. Not sure that this behavior is contractually specified though.

Answer 1

If IDisposable.Dispose were implemented with an unsealed method, then the code for derived types would run before and after the base-type cleanup code; since GC.SuppressFinalize shouldn’t be called until after a derived type has finished its cleanup (including any portions that should perhaps occur after the base type has finished its cleanup), the GC.SuppressFinalize is made in a sealed implementation which in turn calls a virtual method whose signature is void Dispose(bool).

Note that while conceptually it is a good idea to have a virtual method called within a sealed wrapper, there are some flaws in Microsoft’s implementation. Most notably:

1. Because it uses a private flag in the base class indicate whether the object has yet been disposed, but does not use that flag in the wrapper method, every derived class that wishes to avoid duplicate disposal must also have its own disposal flag;
2. There are three scenarios by which a derived `Dispose` call could exit:
   1. It could return normally
   2. It could throw an exception, but nonetheless have achieved everything that can be achieved such that finalization should nonetheless be suppressed (e.g. because an `IDisposable` logging object wrapped a file, and the file data was not written successfully on closure). An ugly situation, but one which isn’t helped by leaving the object registered for finalization.
   3. It could throw an exception, in a scenario where the object should remain eligible for finalization.

   Microsoft’s `Dispose` pattern provides no means of distinguishing among the latter two choices. While leaving an object registered for finalization-based cleanup might in many cases be harmless, it could cause confusion if the `Finalize` method is used to log failures to call `Dispose`.

3. It implies that objects should often hold some resources that they clean up via finalization and some resources that are only cleaned up via `Dispose`, and that unsealed types which don’t clean up anything via finalization should make provision for derived types which might. In practice, classes with finalizers should avoid holding references to any objects not needed for finalization; resources which need finalization should be encapsulated into their own class objects, which should then be held by classes that wouldn’t have to worry about finalizing them.

Back before Microsoft had figured out the best ways to handle unmanaged resources, the Dispose pattern was a good first effort. Today, I would think it better to regard the virtual method’s parameter as being a dummy parameter used to change the signature, than as something meaningful (even though one should always pass True when chaining the virtual method from the wrapper).