2016-09-14 4 views
0

私は自分のInversion of Controlの知識を増やそうとしていて、私が知りたいコードを見つけました。本当のIoCですか?はIoCのこの正しい実装ですか?

public class DepartmentLogic : IDepartmentLogic 
    { 
     private readonly IDepartmentRepository _departmentRepository; 

     public DepartmentLogic(IDepartmentRepository repo) 
     { 
      _departmentRepository = repo; 
     } 

     public DepartmentLogic() 
     { 
      _departmentRepository = new DepartmentRepository(Constants.CONNECTION_STRING_NAME); 
     } 
    } 

単体テストでこのクラスを呼び出すと、模擬IDepartmentRepositoryが渡されます。しかし、すべてのメインアプリケーションコードでは、デフォルトのコンストラクタでクラスを使用し、コンクリートDepartmentRepositoryにニュースを送ります。

これは間違いありませんか?私は、既定のコンストラクタで起きているように、呼び出すクラス内の依存クラスを新規に作成すべきではないこと、そしてこのクラスを作成したクラスで具体的なDepartmentRepositoryの新設が実際に行われるべきだと読んだと思った。

+2

あなたはそうです。そのコードはIoCの目的を完全に破っており、緊密に結合された型に終わっています。単体テストの目的のためだけにIoCコンストラクタを作成したように見えますが、全体的な設計メソドロジとして使用するのではありません。 – itsme86

+0

ありがとう、@ itsme86 - それは私が心配していたものです。私がそれに疑問を抱くと、「単体テストのほかにIoCの他の理由はありません」と尋ねられ、どのように対処するのか分からなくなってしまいます。私はこの声明が無効であり、多くの理由があると信じていますが、私はそれを選ぶことはできません。お手伝いできますか? – Craig

+0

私は[this](https://en.wikipedia.org/wiki/Coupling_(computer_programming)#Disadvantages)はタイトカップリングの欠点をかなりよく表しています。 – itsme86

答えて

2

あなたはクラスに依存性を注入する機能を提供しています。

あなたのアプリケーションが単にデフォルトのコンストラクタを使用していると言うと、あなたは実際に依存関係を注入していないと言います。まだハードコードされています。

さらに進んで、実行時に依存関係を「動的に」作成し、それを(依存性注入フレームワークや他のカスタムメカニズムを介して)クラスに注入するためのメカニズムを提供する必要があります。

+0

ありがとう@ジャスティン... "動的に"依存関係を作成するための何らかの仕組みを提供すると言うと、Unity(IoCコンテナ - 次に理解したいことです)のようなものですか? – Craig

+1

@Craig - 正解(それでなぜ私はDependency Injection Frameworksを挙げたのか)。 Unityは単なる一人です。私はAutofacとnInjectも好きです。 –

+0

コンストラクタで "new"キーワードを使用すると、タイトな結合が導入されるたびに、 – loneshark99

関連する問題