0

特定の依存性注入ライブラリ（Spring、Castle、StructureMap、Ninject ...など）を抽象化するための一連のクラスを知っている人はいますか？

私たちは皆、DIコンテナを使用してコードの特定の実装を抽象化しますが、同じインターフェイス/戦略パターンを使用して、Castle.Windsor、Unityなどの特定の実装を使用して汎用インターフェイスベースのDIコンテナを作成することもできます。

一般に、コンテナからの「GettingandObject」の基本的なパターンはかなり普遍的です。例えば：

IService service = IocContainer.Get<IService>();

IocContainerは、Castle.Windsor、Unity...などの特定のライブラリ実装の汎用ラッパークラスです。

もちろん、「プラグイン」できる特定の実装を作成することに加えて、もちろん、各実装には独自の構成ファイル形式があります。

DIコンテナ用に十分にテストされた既存のラッパークラスに関する提案はありますか？

4

1 に答える 1

3

これらすべてのラッパーとコンテナー抽象化の問題は、すべてのコンテナーが共有する機能の共通サブセットに制限されることです。だからあなたはそれをすべきではありません。代わりに、選択したコンテナを正しく使用してください。

  1. アプリケーションに「Get」を1つだけ入れます-コンポジションルートに
  2. 1つずつサービス登録で使用するのではなく、規則に従ってコンテナーを構成します。これにより、構成が小さくなります。
  3. アプリケーションの初期構成後にインスタンスを作成し、コンテナー構成の一部として実装する必要がある場合は常に、ファクトリインターフェイスを使用します（一部のコンテナーは、この実装を自動的に実行します）

これらの単純なルールを使用すると、コンテナは1つの場所（コンポジションルート）でのみ認識され、コンテナの抽象化は廃止されます。そうすれば、コンテナの全機能を使用できます。

于 2012-04-23T23:39:49.860 に答える