14

StructureMapのようなIoCフレームワークの使用法を理解しようとしていますが、これらの「デザインパターン」は単なるナンセンスであり、コードがさらに複雑になっていると考えざるを得ません。

IoCがいくらか役立つと思う例から始めましょう。

IoCは、MVCフレームワークでコントローラークラスのインスタンス化を処理するときに役立つと思います。この場合、私は.NETMVCフレームワークについて考えています。

通常、コントローラークラスのインスタンス化はフレームワークによって処理されます。つまり、コントローラークラスのコンストラクターにパラメーターを実際に渡すことはできません。これは、IoCフレームワークが役立つ場合があります。IoCコンテナのどこかで、constructorコントローラクラスが呼び出されたときにインスタンス化してコントローラに渡すクラスを指定します。

これは、コントローラーに渡されたオブジェクトをモックできるため、コントローラーを単体テストする場合にも便利です。

しかし、私が言ったように、なぜ人々がコントローラークラスにそれを使用したいのかはある程度理解できます。しかし、それ以外ではありません。そこから、通常の依存性注入を簡単に実行できます。

しかし、なぜ単純にこのようにしないのですか？

public class SomeController
{
    public SomeController() : this( new SomeObj() ) 
    {
    }

    publiv SomeController(SomeObj obj)
    {
        this.obj = obj;
    }
}

これで、サードパーティのIoCフレームワークを使用する必要がなくなり、学習曲線も短くなります。そのフレームワークの仕様にも入る必要がないので。

ユニットテストでオブジェクトをモックすることはできます。だから問題ありません。

あなたが言える唯一のことは、「しかし今、あなたのクラスは緊密に結びついてSomeObjいる」ということです。これは本当です。しかし、誰が気にしますか！？コントローラークラスです！私はそのクラスを再利用するつもりはありません..それで、なぜ私はその緊密な結合について心配する必要があります..？渡されたオブジェクトをモックできます。それが唯一の重要なことです。

では、なぜわざわざIoCを使用する必要があるのでしょうか。私は本当にポイントを逃していますか...？私にとって、IoCパターンは過大評価されたパターンにすぎません。アプリケーションにさらに複雑なレイヤーを追加しています...

4

3 に答える 3

8

あなたは良い質問をします。あなたの例では、IoCはやり過ぎだと思いますが、コードを次のように拡張すると、IoCにこれらすべてを実行させることの利点がわかり始めるかもしれません。

public class SomeController
{
    public SomeController() : this( new SomeObj(new configuration(), new SomethingElse(new SomethingElseToo())) ) 
    {
    }

    publiv SomeController(SomeObj obj)
    {
        this.obj = obj;
    }
}
于 2013-03-18T16:04:14.667 に答える
4

IoCコンテナがあなたのためにできることは複数あります。

明らかなのは、依存関係の実装を提供することです。これは、コントローラーだけでなく、他の場所でも意味があります。に置き換えることにSomeObjしSomeObj2た場合は、57か所ではなく1か所で行うことができます。

もう1つは、ライフサイクルの問題を処理することです。つまり、オブジェクトのスコープ（シングルトン、スレッドごと、リクエストごと、一時的など）を指定できます。

さらに、IoCコンテナは、オプションの依存関係（つまり、プロパティインジェクション）を設定できます。これは、次のように記述するよりも簡単です。

var svc = new Service(new MyRepository())
svc.Logger = logger;
svc.XY = xy

そしてここに述べられているすべての正当な理由：単純なDIコードではなくIoCコンテナが必要なのはなぜですか？

于 2013-03-18T16:03:41.953 に答える
2

しかし、誰が気にしますか！？コントローラークラスです！そのクラスを再利用するつもりはありません。

これは良い点ですが、ライフサイクルが異なるネストされた依存関係がある場合は、コードがどれほどクリーンであるかを検討してください。たとえば、アプリケーションレベルのシングルトンや、「リクエストごと」に必要なものなどを使用できます。IoCを使用すると、コードだけがすっきりし、簡単に変更できます。

于 2013-03-18T16:05:20.397 に答える