Spring.Netの組み込みIoCコンテナをNinjectに置き換えることが可能かどうか知りたいです。私たちは他のプロジェクトでIoCのチームでNinjectを使用しているので、可能であればそのコンテナーを引き続き使用したいと思います。
これは可能ですか？誰かがNinject-Spring.Netアダプターを書いたことがありますか？
編集
Spring.Netパッケージの多くの部分（データアクセス、トランザクションなど）は好きですが、依存性注入コンテナはあまり好きではありません。それをNinjectに置き換えたい
ありがとう
Spring.NET から Ninject への変換について具体的に話すことはできませんが、一般的に、すべてのアプリケーション コードはDI コンテナーに依存しないように記述する必要があります。
DI コンテナーについて考える最良の方法は、ハリウッドの原則です。DI 用語で言えば、DI コンテナーを呼び出さないでください。
つまり、DI の最適なアプリケーションは、コンストラクター インジェクションや抽象ファクトリーなどの単純なパターンを使用することです。
価値のあるほとんどの DI コンテナーは本質的にこれらのパターンを理解しているため、特別な DI コンテナー固有のフープを飛び越える必要はありません。
これは、理想的には、DI コンテナー固有のコードをアプリケーション内の 1 つのファイルにのみ含める必要があることも意味します。この場所はコンポジション ルートと呼ばれ、DI コンテナがオブジェクト グラフ全体を接続し、邪魔にならないようにする場所です。
この原則に従えば、ある DI コンテナーを別の DI コンテナーに簡単に交換できます。
次の投稿に詳細があります。
私は他の答えで言ったことすべてを意味していました。ただし、現在Spring.NET をサービス ロケーターとして使用している場合 (つまり、コンテナーをクエリするコード ベース全体にコードが散りばめられている場合)、その答えはあまり役に立たない可能性があることも認識しています。
このような場合は、Common Service Locatorプロジェクトが役立つことがあります。これは、特定の Service Locator を抽象化し、それらすべてを共通のインターフェイスの背後に隠そうとするオープン ソース プロジェクトです。
彼らは Ninject の実装を持っていないように見えますが、Spring.NET の実装を持っているので、おそらくそこまで行くことができます。
記録として、私は Service Locator をアンチパターンと考えており、Common Service Locator は間違った問題に対する間違った答えであることがわかりました。私の目には、それはまったく冗長ですが、中間ステップとして役立つかもしれません.
ジェフリー、あなたがしようとしていることの例を教えてください。なぜ/どこで/どのように2つのコンテナを混ぜたいのか、あなたの主張がわかりません。コードが完全にコンテナーに依存しない場合、接続を行うためにどちらのコンテナーを使用しても問題はありません。