デカップリングで少し離れすぎているようです。デカップリングが行き過ぎた - 実装DLLは参照されていないので、binフォルダに含まれていません
私はasp.netプロジェクトのソリューションを持っており、私はIinCコンテナとしてNinjectを使用しています。
MVCプロジェクトで使用される重要な部分のほとんどは、専用の 'Contracts'ライブラリからのインターフェイスです。
インターフェイスの実際の実装は、MVCアプリケーションで直接参照されていない他のアセンブリにあります。 彼らは完全に別々です、MVCアプリは契約DLLを知っているだけです。次いで
Ninjectは
今kernel.Load("MyAssPrefix.*"); //load binding modules
kernel.Bind(x =>
{
x.FromAssembliesMatching("MyAssPrefix.*")
.SelectAllClasses()
.BindDefaultInterface();
}); //bind all the rest
（アプリの起動時に）組成ルートにすべての参照コードをロードして、問題がアセンブリの一部ので直接アプリで参照されていないということである、DLLのbinフォルダにコピーされません。
これは実行時に問題が発生します。これは、型を解決してエラーをスローする必要があることを考慮すると、特に困難です。つまり、ある機能が使用されてから数週間後にエラーをコンパイル、
私はいくつかのアプリケーションで共有され、いくつかの明示的なバインディングを指定する 'CompositionRoot'プロジェクトを持っています。もちろん、このプロジェクトには必要なビットがすべて参照として追加されていますが、明示的に呼び出されることはないため、含まれません。
私はそれからランダムクラスを呼び出すアセンブリを、結合することができるモジュールを持つことである私の問題の回避策を持っている（私は単にbinフォルダに必要なDLLをドロップし、それは大丈夫作業開始します） DLLを出力に追加させ、すべて正常に動作するようにするアセンブリです。
public class BindAssembliesModule : NinjectModule
{
#region Overrides of NinjectModule
public override void Load()
{
this.Kernel.Bind(x => x.FromAssembliesMatching(typeof(MyAssPrefix.SomeClass).Assembly.GetName().Name).SelectAllClasses().BindDefaultInterface());
}
#endregion
}
これは、しかし、それは明らかにされていませんいくつかの理由
- のためにハックようだ
- （参照が「optiomizedされていないことを確認する以外に）必要とされていないその冗長コード
- その壊れやすい - 私が選んだクラスを別のアセンブリに移動すると、これは動作しなくなる
- 新しいアセンブリが追加されたときにこのハックについて覚えておく必要がある
これを処理する適切な方法は何ですか、私は間違って何をしていますか？