私はDIとIoCと少し混乱しています。MVCをセットアップし、プロパティの注入にNinjectを使用しましたが、完全に機能します。私のアプリケーションはMvcContribのポータブルエリアを使用するように設定されており、各エリアはプロバイダー、サービス、モデル、コントローラーから含まれています。
あるエリアのプロバイダーは、同じアセンブリまたはサブアセンブリ内の他のプロバイダーにアクセスできます。プロバイダーの依存関係を解決するには、Ninjectも使用するように登録されているDependencyResolver.Cur...を使用します。他のすべてのプロバイダーをコントローラーから最後のレイヤーに渡したくないので、これが良いアプローチであるかどうかを知りたいのですが、プロバイダーから直接アクセスしたいと思います。Coreのような最下位のアセンブリでカーネルのインスタンスを作成して、どこからでも直接アクセスできるようにする必要がありますか？
事前にThnx
更新：通常のクラスでプロパティインジェクションを使用できるかどうかも知りたいです。
コンストラクター インジェクション パターンを中心にすべてのサービス (リポジトリ、アプリケーション サービス、コントローラーなど) を設計する場合DependencyResolver.Current.GetService、クラス内から呼び出す必要はなく、最下位のアセンブリでカーネルのインスタンスを使用できるようにする必要もありません。
すべてのサービスがコンストラクター注入を使用する場合、コンテナーは、ルート タイプが要求されたときに、依存するサービスのオブジェクト グラフを構築できます。この場合は、コントローラー クラスです。DependencyResolverこれを行うと、コードがまたは に直接アクセスする必要がなくなり、コードのKernelテスト、柔軟性、保守が容易になります。DependencyResolverまたは静的インスタンスにアクセスするコードKernelはテストが難しく、その依存関係が隠され、自動化された方法でコンテナーの構成を検証することが難しくなります。
コンストラクター注入を使用する代わりに、プロパティ注入を使用して同じことを実現できます。ただし、プロパティはオプションの依存関係のためのものであるという慣習があるため、Ninject (およびその他のコンテナー) は、コンストラクター引数の依存関係がない場合に発生する例外をスローする代わりに、注入できないプロパティをスキップします (暗黙のプロパティ注入)。 . これにより、アプリケーションの構成エラーを見つけるのがさらに難しくなります。そのため、可能な限り、コンストラクター インジェクションを使用してください。