依存性注入の処理-ロジックはどこに行きますか？

Question

ASP.Net Webサイトと、ビジネスロジック、データアクセスコードなどのサポートクラスライブラリを使用しています。

私は非常に新しく、Unity FrameworkとDependency Injection全体に精通していません。ただし、codeplexでASP.NET 3.5 Portal Starter Kitのソースコードを追跡することで、なんとか機能させることができました。しかし、ここに問題があります：

クラスライブラリはUnityでセットアップされ、いくつかのクラスにはプロパティに[Dependency]属性があります（このためにプロパティセッターインジェクションのみを使用しています）。ただし、Global.asaxはUnityにクラスライブラリ内のインジェクションを処理する方法を指示しています。

これはベストプラクティスですか、それとも他のWebサイト、Webアプリケーション、またはアプリケーションでライブラリを再利用できるように、クラスライブラリが独自のインジェクションを処理する必要がありますか？もしそうなら、インジェクションコードはこのインスタンスのどこに行きますか？

質問がどれほど明確かわかりません。さらに説明する必要がある場合はお知らせください。

Answer 1

Unity（StructureMapユーザー）には慣れていませんが、最終的なマッピングは消費アプリケーションに存在する必要があります。使用しているdllでこれらのマッピングを定義できますが、必要に応じてそれらをオーバーライドすることもできます。たとえば、IFooのインスタンスが必要であり、クラスライブラリにマップされているが、Webサイトに存在する新しいインスタンスを追加して使用したとします。サイトでマッピングを定義すると、物事を疎結合に保つことができますか、それともなぜDIコンテナーを使用するのですか？

Answer 2

個人的には、IOCコンテナーを容易にするためにコードを作成しようとしますが、IOCコンテナーをプロジェクトに強制しようとすることはありません。

ソリューションの内訳は大まかになります： （これらはそれぞれプロジェクトです）。

• Project.Domain
• Project.Persistence.Implementation
• Project.Services.Implementation
• Project.DIInjectionRegistration
• Project.ASPNetMVCFrontEnd（MVCを使用していますが、問題ではありません）。

私はプロジェクトの参照について厳密な境界を維持しようとしています。実際のフロントエンドプロジェクトには、*。Implementationプロジェクトを直接含めることはできません。 （* .implementationプロジェクトには、この場合のドメイン内のインターフェースの実際の実装が含まれています）。したがって、ASPNetMVCFrontEndには、ドメインとDIInjectionWhatever、およびDIコンテナーへの参照があります。

Project.DIInjectionWhateverですべての要素を結び付けます。したがって、このプロジェクトには、実装およびDIフレームワークへのすべての参照が含まれています。コンポーネントの登録を行うコードが含まれています。 Autofacを使用すると、コンポーネントの登録を簡単に分類できるため、このアプローチを採用しました。

ここの例では、実装プロジェクトのコンテナへの参照がありません。それには何の問題もありません。実装に必要な場合は、先に進んでください。