ASP.NETMVCフロントエンドとServiceStack.NETWebサービスを使用してマルチレイヤーアプリを構築しています。
プロジェクトの開始時に、DIにNinjectを使い始めました。ServiceStackをミックスに追加しているので、将来の問題の可能性があるかどうか知りたいです。
ServiceStackライブラリは、デフォルトでIoCコンテナとしてFunqを使用します。すべてが正常に機能しているように見えますが、同じアプリケーションに2つのIoCコンテナーがあると問題が発生するのではないかと思います。
Funq（ServiceStackで使用される）の場合は、静的にバインドされたIOCであり、フル機能のIOCというよりもキャッシュされたコンストラクターデリゲートでいっぱいのC＃ディクショナリに似ています。これはServiceStackのソース形式に含まれており、非常に高速（つまりネイティブ速度に近い）であるために選択されました：http： //www.codeproject.com/Articles/43296/Introduction-to-Munq-IOC-Container-for-ASP -NET.aspx
Funqでの登録は非侵襲的です。つまり、検出したすべての依存関係を登録するすべてのアセンブリを無差別にスキャンしないため、依存関係を手動で登録する必要があります。Funqを使用せず、IContainerAdapterを挿入して別のIOCに委任することにより、別のIOCを使用することを選択した場合、キャッシュされたデリゲートのFunqディクショナリは空になり（つまり、キャッシュミス）、ServiceStackは代わりに優先IOCに依存関係を要求します。
覚えておくべき唯一のことは、Webサービス自体はServiceStackによって登録および自動配線され、優先IOCコンテナーではないため、この場合、IOCは依存関係のリポジトリのように機能します。
将来壊れるかどうかはわかりませんが、壊れるかもしれません。リスクを最小限に抑えるために、インジェクションルーチンの単体テストを試すことができます。そのため、変更を導入するときに、インジェクションルーチンが引き続き機能することを確認するメカニズムがあります。
一般的に、一貫性は品質を向上させると思うので、単一のプロバイダーを使用するようにコードをリファクタリングすることを検討します。私はNinjectを使用しており、サービスとリポジトリを注入するための4つのモジュールがあります。各モジュールには10〜20のインジェクションルーチンが含まれています。これらは1時間以内にリファクタリングできます。プロジェクトのサイズが同じである場合は、リファクタリングして単一のIoCを使用します。
編集 私はServiceStack.Netを使用したことがありませんが、プロジェクトはこのフレームワーク/ツールキットにどの程度依存していますか？近い将来、他のものと交換する可能性がありますか？MVCプロジェクトにどの程度依存していますか？あるIoCを使用する場合の保守コストが別のIoCを使用する場合の保守コストよりも高くなるシナリオを考えようとしています。
Ninjectを見ると、NinjectとNinjectMVC3の拡張機能があります。拡張機能はジョブを簡素化し、他のものと競合しません。私の場合、標準のNinjectをNinject MVC 3に置き換える必要がありました。これは、標準バージョンが実行したすべてのこと（+追加）を実行し、構成が簡単だったためです。
私は言うだろう-それは依存する。
使用しているIoCフレームワークに重複のない異なる依存関係がある場合、問題は発生しません。私が思うに、IoC登録を効果的に倍増する必要がある場合は、依存関係の存続期間をどのように管理しているかに依存すると思います。
すべての依存関係が一時的であるか、カスタムファクトリメソッドを介して作成されている場合は、おそらく問題ありません。ただし、シングルトンまたは「Webリクエストごとのインスタンス」の依存関係をミックスにスローしようとすると、状況が予測不能になる可能性があります。
私はこれまでFunqを使用したことがありませんが、それが有能なIoCコンテナーである場合は、可能であればプロジェクトからNinjectを削除することをお勧めします。アプリケーションでバグを追跡するのが難しいという可能性を排除するだけでなく、コードをよりドライで一貫性のある状態に保つことができます。