現在、使用するプログラム用のオープン ソース SDK を作成しており、内部で IoC コンテナー (NInject) を使用してすべての内部依存関係を結び付けています。
内部としてマークされたオブジェクトがいくつかあるため、パブリック API を混雑させないようにしています。これらのオブジェクトは内部でのみ使用され、工場やその他のオブジェクトなど、ユーザーに表示されるべきではないためです。私が抱えている問題は、NInject が内部オブジェクトを作成できないことです。つまり、すべての内部オブジェクトをパブリックとしてマークする必要があり、パブリック API が混雑します。
私の質問は次のとおりです。この問題を回避する方法はありますか、それともすべて間違っていますか?
PS。InternalsVisiableTo 属性を使用することも考えましたが、それは少し匂いがするように感じます。
他の回答を簡単に見てください。Ninjectに根本的に問題があり、変更または交換する必要があるほど異なることをしているようには見えません。多くの場合、未解決の依存性注入に依存しているため、「そのまま内部に進む」ことはできません。したがって、そもそもNinjectの使用。また、質問が提起された理由であるインターフェイスの内部セットが既にあるようです。
考え: SDK またはライブラリで Ninject を直接使用する際の問題の 1 つは、ユーザーがコードで Ninject を使用する必要があることです。IoC の選択であるため、これはおそらく問題ではないので、とにかく使用するつもりでした。別の IoC コンテナーを使用したい場合は、2 つの複製作業が効果的に実行されます。さらに悪いことに、彼らが Ninject v2 を使用したいのに、あなたが v1.5 を使用した場合、状況は本当に複雑になります。
最良のケース:クラスをリファクタリングして依存性注入を介して必要なものをすべて取得できる場合、ライブラリ コードはIoC コンテナーを必要としないため、これが最もクリーンです。アプリは依存関係を結び付けることができ、フローするだけです。ただし、ライブラリ クラスは、インジェクションでは解決できない依存関係を持つインスタンスを作成する必要がある場合があるため、常に可能であるとは限りません。
提案: CommonServiceLocator (およびそのための Ninject アダプター) は、この状況 (依存関係のあるライブラリ) 用に特別に設計されています。CommonServiceLocator に対してコーディングすると、アプリケーションは実際にインターフェイスをサポートする DI/IoC を指定します。
アプリにNinjectとCommonServiceLocator を持たなければならないのは少し面倒ですが、CommonServiceLocator は非常に軽量です。SDK/ライブラリ コードは、かなりクリーンな CommonServiceLocatorのみを使用します。
InternalsVisibleToソリューションに投票します。全く臭いではありません、本当に。属性のポイントは、必要な種類の動作を有効にすることです。したがって、あらゆる種類の手の込んだフープを飛び越えて、それなしで動作させるのではなく、フレームワークが提供する機能を使用して、この特定の問題を解決します。
また、選択したコンテナーをユーザーから非表示にする場合は、ILMergeを使用してNinjectアセンブリをSDKアセンブリと組み合わせ、/ internalize引数を適用して、Ninjectアセンブリの可視性を内部に変更することをお勧めします。名前空間がライブラリから漏れることはありません（申し訳ありませんが、ILMergeドキュメントへのリンクをオンラインで見つけることができませんでしたが、ダウンロードにドキュメントファイルがあります）。ILMergeをビルドプロセスに統合することについてのこの素晴らしいブログ投稿もあります。
私はあなたがそれを必要としないと思います。IoC は公開用です。内部構造に直進します。
しかし - それは私の直感です...