6

DIを使用してオブジェクトを管理する方法を考えています。私がクラスを持っているとしましょう

class Foo : IFoo, IDisposable
{
    // ...
}

次に、このクラスは別のクラスに注入されます

class Bar
{
    public Bar(IFoo foo)
    {
        this.Foo = foo
    }

    IFoo Foo { get; set; }
 }

次に、これをいくつかのスコープでバインドします（私の例ではMVCとNinjectを使用しています）

this.Bind<IFoo>().To<Foo>().InRequestScope();

依存性注入フレームワークはのライフサイクルを処理するので、FooIDispoableを実装する必要がありBarますか？私の考えでは、DIはのライフサイクルを管理しているFooので、別のクラスがを使用している場合に備えて、それに触れないでくださいFoo。また、使い捨てオブジェクトはBarコンストラクターパラメーターとして渡されるため、使い捨てオブジェクトをラップBarしないため、ガベージコレクション後にの呼び出し元がどのように使用したいかがわかりません。これは正しいですか？BarFooBar

4

2 に答える 2

3

これは、寿命を管理する上での一般的な問題です。基本的なルールは、オブジェクトを作成する人がそのインスタンスの所有権を持っているということです。所有者は、そのインスタンスを破棄/破棄する必要があります。所有権を他の誰かに譲渡することができます。これにより、その「他の誰か」がそのインスタンスを破棄する責任を負います。

あなたの場合、FooインスタンスはBarによって作成されていないため、barはそのインスタンスを破棄する責任を負いません。Ninjectはそのインスタンスを作成したので、クリーンアップを担当します。

所有権を譲渡することはできますが、これは明確なものでなければなりません。明示的な所有権の受け渡しの良い例は、ファクトリデザインパターンです。

IFoo CreateNewFoo();

このメソッドは新しいIFooインスタンスを作成しますが、所有権を呼び出し元に戻すことは明らかです。

所有権を渡す悪い方法の良い例は、.NETのStreamReaderクラスです。コンストラクターで使い捨てオブジェクトを取りますが、所有権を取ります。ドキュメントには、クラスが特定のオブジェクトを破棄すると記載されていますが、この動作は、所有権の一般的な規則に反するため、多くの開発者を驚かせます。Microsoftは、特定のストリームの破棄を抑制できるctorオーバーロードを追加することにより、.NET4.5でこれを最終的に修正しました。

于 2012-12-10T14:54:17.453 に答える
3

はい、あなたの仮定は正しいです。Ninjectはオブジェクトを破棄します。

于 2012-12-07T09:04:13.063 に答える