MVCアプリケーションでIoCフレームワークを使用するとは何ですか？

Question

私はStructureMapのようなIoCフレームワークの使い方を理解しようとしていますが、これらの "デザインパターン"は単なるナンセンスなので、コードをもっと複雑にするとは考えられません。

私はIoCがやや便利だと思う例から始めましょう。

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

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

これは、渡されたオブジェクトをモックすることができるので、コントローラをユニットテストするときにも便利です。

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

しかし、単にこのようにそれをしない理由：

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

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

今、あなたはまた、より低い学習曲線を意味任意のサードパーティ製のIoCフレームワークを使用する必要はありません。あなたはそのフレームワークの仕様にも入る必要はないからです。

ユニットテストでもオブジェクトをモックできます。だから問題はない。

「あなたのクラスはが密接に〜SomeObjになりました」としか言えません。 これは本当です。しかし、誰が気に！これはコントローラクラスです！私はそのクラスをいつも再利用するつもりはない。だから、どうしてこのタイトなカップリングについて心配すべきなのか？私はそれに渡されるオブジェクトを模擬することができます。それが唯一の重要なことです。

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

Answer 1

あなたは良い質問をすると、あなたの例では、私はのIoCは/可能性があろうと言うでしょうあなたのコードが次のように拡張されたと考えると、IoCですべてのことができるようになるという利点があるかもしれません。

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

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

Answer 2

IoCコンテナがあなたにできることはいくつかあります。

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

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

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

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

とここに記載されたすべての正当な理由：Why do I need an IoC container as opposed to straightforward DI code?

Answer 3

だれが気にする！？これはコントローラクラスです！私は クラスは、今まで...

これは良い点であることを再利用していますが、別のライフサイクルで、依存関係を入れ子にした場合、クリーナーは、コードです方法を検討するつもりはありません。たとえば、アプリケーションレベルのシングルトン、「要求ごと」などが必要なものをいくつか用意することができます。 IoCは、コードをきれいにするだけでなく、変更も簡単です。