1

ますます複雑化するエンタープライズサービスのシステムで依存関係を切り離すには、絶対にIoCコンテナを使用する必要があります。私が直面している問題は、構成（別名登録）に関連する問題です。現在、開発から本番、そしてその間の4つの異なる環境があります。これらの環境には、環境ごとにわずかに異なる多数の構成があります。ただし、現在考えられるすべてのケースで、コンポーネント間の依存関係は環境ごとに異なりません。ただし、何かを見逃したり、明らかに変更されたりする可能性があります。

したがって、最終的な質問は、IoCフレームワークを使用して同様の経験をした人はいますか？または、ある種の規則や簡略化された構成情報を通じて柔軟な登録を提供するフレームワークを他のフレームワークよりも推奨できる人はいますか？それでも流暢なインターフェースの恩恵を受けることができるのでしょうか、それともXMLに固執しているのでしょうか？XMLを避けたいのです。

編集：これは.Net環境であり、Windsor、Ninject、およびAutofacを見てきました。Autofacのラムダ式のサポートは他の方法とは少し異なるようですが、これらはすべて登録の両方の方法（流暢とXML）をサポートしているようです。誰かが同様のマルチデプロイメント環境でそれを使用しますか？

4

4 に答える 4

3

コンテナを抽象化し、別のコンテナを使用できるようにしたい場合は、ここで試した方法で注入可能にすることを検討してください

于 2009-02-09T05:26:29.930 に答える
2

私はNinjectを使用しています。依存関係を構成するために Xml を使用する必要がないという事実が気に入っています。C# コードをそのまま使用できます。それを行う方法も複数あります。他のライブラリにその機能があることは知っていますが、Ninject は高速なインスタンス化を提供し、非常に軽量で、条件付きバインディングがあり、コンパクトなフレームワークをサポートし、Silverlight 2.0 をサポートしています。また、将来別のフレームワークに切り替える場合に備えて、その上にラッパーを使用します。フレームワークを決定するときは、必ず Ninject を試してください。

于 2008-09-05T12:44:47.577 に答える
1

Ayendesサイのコモンズを見てください。彼はIoCコンテナの抽象化を使用しています。いつでもコンテナを切り替えることができるように。container.Resolveのようなものは、すべてのコンテナーに常に存在します。

私はStructuremapを使用して、流暢なインターフェイスとXMLを備えた汚い作業を行っています。これは、実行したいほとんどのことに対して十分に強力です。それぞれに独自の長所と短所があるので、簡単に切り替えることができるように少し抽象化するのが良いです（それらがどれくらいの期間になるかはわかりません）。残りの部分については、Spring.Net、Castle windsor、Ninject、StructureMapはもうそれほど離れていないと思います。

于 2008-09-05T12:02:26.227 に答える
1

特定のケースに適しているかどうかはわかりません。どのプラットフォームで作業しているかについては言及されていませんが、CastleWindsorのIOCフレームワークで大きな成功を収めています。依存関係は構成ファイルで設定されます（これは.NETフレームワークです）

于 2008-09-05T04:18:52.567 に答える