IoCコンテナの設定/登録
-
09-06-2019 - |
質問
ますます複雑化するエンタープライズ サービス システムの依存関係を分離するには、IoC コンテナを必ず使用する必要があります。私が直面している問題は、構成 (別名:登録)。現在、開発から本番まで、およびその中間の 4 つの異なる環境があります。これらの環境には、環境ごとにわずかに異なる多数の構成があります。ただし、すべての場合において、 今のところ思いつくのは, 、コンポーネント間の依存関係は環境ごとに異なりませんが、何かを見逃していた可能性や、明らかに変更された可能性があります。
究極の質問は、IoC フレームワークを使用して同様の経験をした人はいるかということです。あるいは、ある種の規約や簡素化された構成情報を通じて、柔軟な登録を提供するフレームワークを別のフレームワークよりも推奨できる人はいますか?まだ流暢なインターフェイスの恩恵を受けることができるでしょうか、それとも XML に行き詰まっているのでしょうか -- XML 地獄は避けたいと思っています。
編集: これは .Net 環境であり、Windsor、Ninject、Autofac を検討しています。これらは現在、両方の登録方法 (Fluent と XML) をサポートしているようですが、Autofac のラムダ式のサポートは他のものとは少し異なるようです。同様のマルチ展開環境でそれを使用している人はいますか?
他のヒント
コンテナを抽象化し、別のコンテナを使用できるようにしたい場合は、私が試した方法でコンテナを注入可能にすることを検討してください。 ここ
それがあなたの特定のケースに適しているかどうかはわかりません。どのプラットフォームで作業しているかについては言及されていませんでしたが、私は非常に成功しました。 キャッスル ウィンザーの IOC フレームワーク. 。依存関係は構成ファイルで設定されます (.NET フレームワークです)。
アイエンデスのサイの共有地を見てください。彼は IoC コンテナ上で抽象化を使用しています。そのため、いつでもコンテナを切り替えることができます。container.Resolve のようなものは、すべてのコンテナに常に存在します。
私は汚い仕事をするために Structuremap を使っています。Structuremap は流暢なインターフェイスと XML を備えており、やりたいことのほとんどには十分に強力です。それぞれに独自の長所と短所があるため、簡単に切り替えられるように少し抽象化するのが良いでしょう (どれくらい存続するかわかりません)。残りについては、Spring.Net、Castle winsor、Ninject、StructureMap は、それほど遠く離れていないと思います。