Ninjectと同じ質問があります-静的クラスのカーネル? しかし、私はWCFを使用しておらず、クラスライブラリのみを使用しています。
静的カーネルを使用する方がよいですか、それともいつでもインスタンス化する方がよいですか?私のUI(現在はMVCアプリケーションにあります)はサービスを消費しますが、静的カーネルを呼び出しますか?最善のアプローチは何ですか?
Ninjectと同じ質問があります-静的クラスのカーネル? しかし、私はWCFを使用しておらず、クラスライブラリのみを使用しています。
静的カーネルを使用する方がよいですか、それともいつでもインスタンス化する方がよいですか?私のUI(現在はMVCアプリケーションにあります)はサービスを消費しますが、静的カーネルを呼び出しますか?最善のアプローチは何ですか?
IoC を使用する場合、推奨されるアプローチは、カーネルをできるだけ使用しないことです。初期化時にすべてを接続するために使用し、その後はバックグラウンドにすばやく静かにフェードインする必要があります。したがって、「ハリウッドの原則」が適用される場合は、「IoC コンテナーを呼び出すのではなく、呼び出してください!」です。カーネルを含む静的クラスは、Service Locator アンチパターンと呼ばれるものです。こちらを参照してください。
つまり、毎回カーネルを作成したり、静的クラスを参照したりする代わりに、コンストラクター注入を使用して依存関係を注入する必要があります。
Ninject for MVC拡張機能があるので、MVC UIに使用しないのはなぜですか?
また、WCFサービスは独自の構成ルートを持つことができます。確かに、NinjectModule
両方で1つの実装を再利用できます。Kernel
したがって、静的である必要はなく、すべてのコンポジションルートNinjectModule
で実装を再利用するだけです。
たとえば、アプリケーションの構成は次のとおりです。
public class ApplicationModule : NinjectModule
{
public override void Load()
{
Bind<IAbstraction>().To<Implemtation>();
// and other general bindings
}
}
public class YourWebApplication : NinjectHttpApplication
{
public override IKernel CreateKernel()
{
var kernel = new StandardKernel(new ApplicationModule ());
// add some UI specific bindings, for example authorization
kernel.Bind<IAuthProvider>().To<AuthProvider>();
// binding between service contract and implementation/client
kernel.Bind<IServiceContract>().To<WcfServiceClient>();
return kernel;
}
}
そして、Ninjectを使用したWCF:
public class Global : NinjectWcfApplication
{
protected override IKernel CreateKernel()
{
var kernel = new StandardKernel(new ApplicationModule ());
// add some service specific bindings, for example authorization
// service has also some other small services that i call providers
// so ex Service 1 : has Iprovider1 Iprovider2 Iprovider3
kernel.Bind<IProvider1>().To<Provider1>();
kernel.Bind<IProvider2>().To<Provider2>();
kernel.Bind<IProvider3>().To<Provider3>();
return kernel;
}
}
Mark Seemann は、彼のブログで次のように述べてい ます。ライブラリとフレームワークはそうすべきではありません。
それが私の質問への答えです。構成のルートパターンをよりよく理解しています。AkimとAlexander Rの助けに感謝します