滥用IDisposable是否受益于"使用"被认为有害的陈述?

wal*_*pus 14 .net c# idisposable

接口的目的IDisposable是以有序的方式释放非托管资源.它与using定义范围的关键字密切相关,该关键字在有问题的资源被处置之后.

因为这种机制非常简洁,所以我一直试图让类实现IDisposable能够以其不适合的方式滥用这种机制.例如,可以实现类来处理嵌套的上下文,如下所示:

class Context : IDisposable
{
    // Put a new context onto the stack
    public static void PushContext() { ... }

    // Remove the topmost context from the stack
    private static void PopContext() { ... }

    // Retrieve the topmost context
    public static Context CurrentContext { get { ... } }

    // Disposing of a context pops it from the stack
    public void Dispose()
    {
        PopContext();
    }
}
Run Code Online (Sandbox Code Playgroud)

调用代码的用法可能如下所示:

using (Context.PushContext())
{
   DoContextualStuff(Context.CurrentContext);
} // <-- the context is popped upon leaving the block
Run Code Online (Sandbox Code Playgroud)

(请注意,这只是一个例子而不是这个问题的主题.)

Dispose()离开using语句范围时被调用的事实也可以被利用来实现依赖于范围的各种事物,例如计时器.这也可以通过使用try ... finally构造来处理,但是在这种情况下,程序员必须手动调用一些方法(例如Context.Pop),using构造可以为此做.

这种用法IDisposable文档中所述的预期目的不一致,但诱惑仍然存在.

有没有具体的理由说明这是一个坏主意并永远消除我的幻想,例如垃圾收集,异常处理等的复杂性.或者我应该继续通过这种方式滥用这种语言概念来放纵自己?

spe*_*der 10

所以在asp.net MVC视图中,我们看到以下构造:

using(Html.BeginForm())
{
    //some form elements
}
Run Code Online (Sandbox Code Playgroud)

虐待?微软说不(间接).

如果你有一个构造,一旦你完成它需要一些事情发生,IDisposable通常可以非常好地工作.我不止一次这样做过.

  • 与交易范围类似. (4认同)
  • @ChrisDunaway`using`已经是`try/finally`的语法糖,但有一个方便的标准接口.没有`IDisposable`,调用者需要知道如何清理,而`using`会给创建者带来负担. (2认同)