Castle.Windsorインストーラを使用したソリューションアーキテクチャ

Question

私は自分の組織に依存性注入フレームワークを導入するためにかなりの研究を行ってきました。これまでのところ、私の研究はCastle.Windsorに大きく焦点を当てていました。この研究は、インストーラ、インターセプタ（特にロギングクロスカッティングの問題のための）、設備などのコンセプトにつながりました。これらはすべて私が使いたいと考えています。

私の解決策（私のプロジェクトアーキテクチャはビジュアルスタジオで）をどのようにして構想するのですか？将来のある時点でDIフレームワークを置き換えることができます（2年後の方が良いかもしれません）。

サービスロケーションのcommon-service-locatorを使用する組織のフレームワークライブラリを開発していますが、コンテナの設定はどうですか？

サービスインプリメンテーションと同じプロジェクトにインストーラを配置した場合、フロントエンドプロジェクトはインストーラでコンテナを設定するときに、これらのプロジェクトを参照する必要があります（流暢な設定と仮定します）。これらのサービス実装がデータアクセス層の懸念事項であるとすれば、私はフロントエンドがこの特定の層を参照することを本当に望んでいません。

私の質問には何も触れられていないので、自分の考え方に間違っているかもしれないと思っています。

とにかく私は、プロジェクトの各レイヤー（例：XXXOrganisation.Data.Model.NHibernate - 仕様の具体的な実装を格納している概念）を開発しました。等）は、インストーラ（例えば、XXXOrganisation.Data.Model.NHibernate.Castle）のようなコンテナ構成に関する懸案事項に対応するDLLプロジェクトを持っています。私の計画はILMergeを使用して、城固有の構成用のすべてのプロジェクトをフロントエンド（Webアプリケーション）が参照する1つのプロジェクトにマージすることでした。

これは実行可能なアプローチですか？

上記以外にも、私はロッカーのようなものにインセプターを使用するための特定のサービスを登録したいと思います。私は自分の城の構成プロジェクト（インストーラを含む）がこの種のもののためにXXXOrganisation.Aop（または単にXXXOrganisation.Castleベースプロジェクト）を参照するかもしれないと考えていた...

私は、私の質問に手伝ったり、アドバイスをもらったりしてください。

親切に、 Ryan。

Answer 1

フレームワークまたはライブラリ（not the same thing）を作成する場合は、コンテナをまったく使用しないでください。代わりに、architect it to support any kind of Dependency Injectionを指定してください。

アプリケーションは、コンポジションルートから、DIコンテナを使用する必要があります。