内部オブジェクトでIoCを使用する

Question

現在、使用しているプログラムのオープンソースSDKを書いています。内部ですべての依存関係を結びつけるために、内部でIoCコンテナー（NInject）を使用しています。

内部としてのみマークされているオブジェクトがいくつかあるので、パブリックAPIは内部でのみ使用され、工場やその他のオブジェクトのようなものはユーザーに表示されません。私が抱えている問題は、NInjectが内部オブジェクトを作成できないことです。つまり、すべての内部オブジェクトをパブリックにマークする必要があるため、パブリックAPIが混雑します。

私の質問は、この問題を回避する方法がありますか、それともすべて間違っていますか？

PS。 InternalsVisiableTo属性を使用することを考えましたが、それは少し臭いのように感じます。

Answer 1

他の回答をざっと見てください： Ninjectに根本的な問題があり、修正または交換が必要なほど何か違うことをしているようには見えません。多くの場合、「[内部]を直進」することはできません。未解決の依存性注入に依存しているためです。したがって、そもそもNinjectの使用方法です。また、既に内部インターフェイスのセットを持っているように思えるので、問題が提起されました。

思考： SDKまたはライブラリでNinjectを直接使用する場合の1つの問題は、ユーザーがコードでNinjectを使用する必要があることです。 IoCの選択であるため、これはおそらく問題ではないので、とにかくそれを使用します。別のIoCコンテナを使用したい場合、2つの重複する作業を効果的に実行できます。さらに悪いことに、彼らがNinject v2を使用したい場合、v1.5を使用しているとしたら、それは状況を本当に複雑にします。

ベストケース：依存性注入を介して必要なすべてを取得するようにクラスをリファクタリングできる場合、ライブラリコードは any を必要としないため、これが最もクリーンですIoCコンテナー。アプリは依存関係を結び付けることができ、流れるだけです。ただし、インジェクションでは解決できない依存関係を持つインスタンスをライブラリクラスが作成する必要がある場合があるため、これは常に可能とは限りません。

提案： CommonServiceLocator （およびそのためのNinjectアダプター）は、この状況（依存関係のあるライブラリー）専用に設計されました。 CommonServiceLocatorに対してコーディングすると、アプリケーションは実際にどのDI / IoCがインターフェースをサポートするかを指定します。

アプリでCommon ServiceLocatorを する必要がありますが、CommonServiceLocatorは非常に軽量です。 SDK /ライブラリコードは only でかなりクリーンなCommonServiceLocatorを使用しています。

Answer 2

あなたはそれさえ必要ないと思う。 IoCは公開用です。内部を直進します。

しかし、それは私の直感です...

Answer 3

外部APIとは異なるセカンダリ内部APIを作成します。手動で分割する必要があるかもしれません...

Answer 4

InternalsVisibleToソリューションに投票します。全く臭いはない、本当に。属性のポイントは、あなたが望む種類の動作を有効にすることです。そのため、あらゆる手の込んだフープを介して物事をそれなしで機能させるのではなく、この特定の問題を解決するためにフレームワークが提供する機能を使用してください。

ILMerge を使用してNinjectアセンブリをSDKアセンブリと結合し、 / internalize 引数を適用してNinjectアセンブリの可視性を変更しますNinjectネームスペースがライブラリからリークしないようにします（申し訳ありませんが、オンラインでILMergeドキュメントへのリンクを見つけることができませんでしたが、ダウンロードにはドキュメントファイルがあります）。また、ILMergeの統合に関する素敵なブログ投稿もあります。ビルドプロセスに。

Answer 5

次のことができます

• Ninjectの変更
• 別のコンテナを選択