一般的なIoCの練習 - サービスがお互いに依存するのは間違っていますか？

Question

今、IoCコンテナ（私の場合はNinject）に依存しないアセンブリで定義されているサービスがいくつかあります。メインプロジェクトでは、コンテナに登録されたデータアクセス用IRepositoryがあります。

this.Bind<IRepository>().To<EntityFrameworkRepository<MyDatabaseEntities>>(); 

私もIAuthenticationServiceとIErrorLoggerサービスは、その具体的な実装、私は彼らのロジックのためのリポジトリを使用する場合、登録されています。しかし、私はこれをいかに最高に達成するかについてはわかりません。現在、両方の具体的な実装上の私のコンストラクタはIRepositoryパラメータを取ると、私はそれらを登録するときにそれを渡します。ここでは

this.Bind<IAuthenticationService>().To<MyAuthenticationService>(). 
       WithConstructorArgument("myRepository", ctx => ctx.Kernel.Get<IRepository()); 

は、私はちょうどIRepositoryインスタンスを取得し、コンストラクタにそれを渡すためにコンテナに伝えます。

サービスアセンブリをninjectや共通サービスロケータ（CSL）に依存させることについて正しくは感じませんでしたが、現在の方法についてもわかりません。私は意見や代替ソリューションを探しています。

私の他のサービスでIRepositoryを使用しない場合は、基礎となるIRepositoryタイプ（偽のデータと実際のデータの両方のAuthenticationServiceなど）ごとに、これらのサービスの新しい具体的な実装を作成する必要があります。それは多くの論理反復であろう。

Answer 1

あなたのサービスアセンブリはNinjectに依存するべきではなく、あなたの具体的な型を登録するインターフェイス上でのみ使用してください。 IoCコンテナは、クラスに依存関係を注入するための集約ルートでなければなりません。一方、集約ルート/ Ninjectカーネルを含むアセンブリは、具体的な型を含むすべてのアセンブリに依存します（それ以外はどのようにそれらを解決できますか？）。

のIoCと一般的には、あなたはここにHollywood principleを適用する必要があります - あなたは（すべての可能であればコンストラクタ・インジェクションを使用して）あなたの具体的なオブジェクトインスタンスにに依存関係を与える必要があり、オブジェクトのインスタンスは、それらの依存関係のためを尋ねるせません。依存関係の解決を再帰的に動作しますので、

あなたがWithConstructorArgument()に使用する例は、実際にはまったく必要とするべきではありません：あなたは、コンテナでIRepositoryとIAuthenticationServiceの両方を登録しているので、両方を解決する方法を知っています。 IAuthenticationServiceはAuthenticationServiceにバインドされているため、コンストラクタ引数はタイプIRepositoryであり、自動的に解決されるため、コンストラクタ引数を指定する必要はありません。繰り返しに関しては

- もちろん、あなたがこれらのリポジトリの異なる振る舞いをしたいと仮定するとさまざまなリポジトリのタイプのIRepositoryため異なる実装を作成する必要があります。