6

皆さんに質問です。

私の会社では、Microsoft の MVC フレームワーク内で動作するアプリケーションを開発しています。実装しているコントローラー クラスは、 MVC 基本クラス Controllerから継承します。例：

public class MyController: Controller
{
    protected bool IsDisposed { get; set; }
… various methods…
 }

チームで行っている議論は、Dispose() パターンを中心にしています。基本的に、これには、できれば Microsoft が承認したパターンに従って IDisposable インターフェイスを実装する必要があります。

たとえば、次のリンクを参照してください: http://msdn.microsoft.com/en-us/library/fs2xkftw%28v=vs.110%29.aspx

興味深いことに、コントローラー クラスは、管理対象または管理対象のいずれのリソースも所有していません。その結果、Dispose(bool) の実装が大幅に簡素化されます。

protected override void Dispose(bool disposing)
{
    IsDisposed = true;
    base.Dispose(disposing);
}

IsDisposed次のメソッドで使用されるプロパティの使用 (または必要性) については、いくつかの意見の相違があります。

protected void ThrowIfDisposed()
{
    if (IsDisposed) throw new ObjectDisposedException(“MyController”);
}

このメソッドは、「実際の」作業を行うすべてのメソッドの開始時に呼び出されます。ここでの考え方は、破棄されたオブジェクトを再度使用してはならないため、ObjectDisposedException をスローする必要があるということです。もう 1 つの意見は、 (プロパティの設定と基本クラスの呼び出しDispose(bool)以外は) "何も" しないため、"処分された" オブジェクトは実際には使用できない状態ではないため、スローする理由がないというものです。したがって、実装する理由さえありません。IsDisposedDispose(bool)Dispose(bool)

これに対する議論は、MyController が破棄され、そのメソッドの 1 つが呼び出されたときにスローする必要があるため、将来のバージョンでマネージド リソースおよび/またはアンマネージド リソースが追加されても動作が変わらないというものです。

この最後の点に対する議論は、 MyController は将来のバージョンでリソースを追加するべきではなく、将来リソースを追加する必要が生じた場合に派生させる必要があるということです。追加の質問は、(ライブラリ) クラス Controller が実装しないのはなぜThrowIfDisposed()ですか?

つまり、要約すると、派閥 1 は実装したいとDispose(bool)考えThrowIfDisposed()ており、上記のように、派閥 2 はそれらが不要であると考えており、それらを廃止したいと考えています。

どちらの観点にもメリットがあると思いますが、本当に決心することはできません。意見？

4

3 に答える 3

7

興味深いことに、コントローラー クラスは、管理対象または管理対象のいずれのリソースも所有していません。

その後、IDisposable パターンは必要ありません。

このメソッド [ ThrowIfDisposed()] は、「実際の」作業を行うすべてのメソッドの最初に呼び出されます。

ここでの質問は次のとおりです。なぜですか？

使用可能/放棄された状態を追跡したい場合は、それを IsDisposed と呼ばないでください。

(ライブラリ) クラス Controller が ThrowIfDisposed() などを実装しないのはなぜですか?

役に立たないからです。

最初に戻りましょう。なぜ誰かがこれが必要だと考えたのでしょうか? それはなんのためですか？
そのまま剥がせるようです。

于 2014-07-05T07:38:39.013 に答える