当我的控制器的字段实现IDisposable时，该如何处置？

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

The controller class in ASP.NET MVC has correctly implemented IDisposable interface. For further reference, check this page on MSDN page that exactly specifies this.

To plug into the IDisposible interface, you need to override the protected dispose method that you have figured out and put the logic to dispose "your own" class there.

Answer 2

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 (eg 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).

Answer 3

1）在您当前的类上实现该接口，并执行您想做的事情2）在您的基类中实现该接口，然后在该类中对其进行覆盖3）仅在您的基类中实现该接口，并且不要覆盖您的代码看起来很奇怪，您有一个抽象类，并且提供了实现逻辑