7

IoCコンテナをカプセル化するために余分な労力を費やすことが理にかなっているかどうかを判断しようとしています。経験によれば、アプリとサードパーティコンポーネントの間にカプセル化のレイヤーを配置する必要があります。これがやり過ぎに隣接しているかどうかはわかりません。

コンテナを切り替えたいと思う状況が思い浮かびます。たとえば、現在のコンテナのメンテナンスが中止されたり、別のコンテナの方が軽量でパフォーマンスが高く、ニーズに合っていることが証明されています。これが発生した場合、私は潜在的に多くの再配線を行う必要があります。

明確にするために、私はタイプの登録と解決のカプセル化を検討しています。解決策をカプセル化するのは簡単だと思います。ヘルパー/utilクラスをコンテナに委任するのが一般的な方法だと思います。

編集：

型の安全性、コンパイル時のチェック、およびリファクタリング性のために、プログラムで型を接続することを好むことが前提です。私が自分自身を保護しようとしているのは、このコードとコンテナーへの依存関係です。

同じ関係を共有する他のいくつかのプロジェクトにもIoCコンテナーを使用していますが、コンテナーを操作するのは面倒なので、変更したいと思います。ただし、変更すると、登録コードの再利用性が失われます。したがって、なぜ私はカプセル化を考えているのですか。それは大きな負担ではありませんが、それでも私が軽減したいものです。

私が探しているのは：

  • コンテナ/コンテナのバージョンの変更による影響を最小限に抑える
  • 異なるコンテナを使用する可能性のあるプロジェクト全体で、ある程度のタイプ登録の一貫性を提供します
  • 私にとって意味のあるインターフェースメソッドを提供します（RegisterType <T、T>（SomeLifetimeProvider）ではなくRegisterSingleton <T、T>-例としてUnityを使用）。
  • 条件/スケーラビリティ要件の変化に応じてコンテナを拡張します。たとえば、解決/登録中にキャッシュやロギングなどを追加します。
  • タイプマッピングを登録するための独自のモデルを提供します。
    • アセンブリ/パッケージにRegistrationHandlerオブジェクトの束を作成したいとします。そうすれば、登録の責任を複数のクラスに簡単に分離し、他の場所でコードを変更することなく、これらのハンドラーを自動的に取得できます。

これは少し主観的なことだと思いますので、賛否両論が役立つかもしれません

ありがとう！

4

4 に答える 4

7

後で、IOCコンテナを実際に変更する必要がある場合にのみ行ってください。

非侵襲的なIOCコンテナを選択します。つまり、相互に接続されているオブジェクトがIOCコンテナに依存していない場合です。この場合、カプセル化するものは何もありません。

コンテナへの依存関係が必要なIOCコンテナを選択する必要がある場合は、可能な限り最も単純な依存関係/APIを備えたものを選択してください。このIOCコンテナーを置き換える必要がある場合（おそらくそうしないでしょう）、新しいAPIを古いAPIにブリッジするアダプターを実装します。

つまり、最初のIOCコンテナーを将来のコンテナーのインターフェースを定義するコンテナーにして、独自のコンテナーを発明する必要がないようにします。この種の作業は、絶対に必要になるまで遅らせることができます。

編集：

次のいずれかを除いて、型安全性を保証する方法がわかりません。

  1. IOC構成ファイルまたは同等のものを書き込むビジター実装とともに、Builderパターンの比較的複雑な実装を設計します。
  2. タイプセーフなIOC構成DSLの実装。（スワップ可能なIOCコンテナーを必要とする複数のアプリがある場合の私の選択。）
于 2009-11-19T02:23:00.803 に答える
1

ええ、それのために行きます。それはそれほど多くの余分な努力ではなく、あなたが言うように、それはあなたにサードパーティのコンポーネントからのより良い分離を与えます。

また、より良いものを見つけた場合は、IoCコンテナを簡単に切り替えることができることも意味します。私は最近、Spring.netIoCコンテナを構造マップに交換することでこれを行いました。

codeplex上のASP.NETMVCContribプロジェクトは、開始するのに非常に適した場所です。これは私が私の実装に基づいたものです。

于 2009-11-19T02:13:18.107 に答える
1

実際に必要な場合にのみ何かを実行することをお勧めします。将来必要になると思われること（いわゆるYAGNIの原則）をコーディングしないでください。アーキテクチャに問題がなければ、実際に必要になった場合は、コンテナを簡単に変更できます...

この種の柔軟性が必要だと思われる場合は、CodePlexのCommonServiceLocatorプロジェクトをご覧ください。それはまさにあなたが探していることをします：様々なIoCコンテナに共通のファサードを提供します。

HTH！

于 2009-11-19T02:46:56.540 に答える
1

IOCコンテナー自体をカプセル化するのではなく、IOCコンテナーとの相互作用の場所を分離することを好みます。たとえば、ASP.Net MVCでは、通常、コンテナーへの公開をコントローラーファクトリとglobal.aspx.csファイルに制限します。このファイルは通常セットアップされます。

私の考えでは、IOCコンテナーについて知っているコードをたくさん持つことは、複雑さを増すアンチパターンです。オブジェクトがIOCコンテナに依存関係を自由に尋ねるコードをかなりの量見てきましたが、基本的にIOCコンテナをメンテナンスの多いサービスロケータに減らしました。

IOCコンテナーは依存関係を任意の深さまで解決できるため、コントローラーファクトリを制御コンテナーの反転に関与するコンポーネントにするのは非常に簡単です。各コントローラーのコンストラクターは、基本的に、必要なサービス/リポジトリー/ゲートウェイを指定します。

私のアプリの場合、IOCコンテナーを交換することは、基本的に、コンテナーを構成し（バインディングなどを指定する）、コントローラーファクトリを接続するコードを書き直すことです。サービスとして公開されるアプリの場合、同じ基本的な考え方が合理的に管理可能である必要がありますが、ランタイムの制約によっては、コンストラクターインジェクションではなくセッターインジェクションを使用する必要がある場合があります。

于 2010-12-13T22:17:50.043 に答える