web-dev-qa-db-ja.com

UnityContainer.ResolveまたはServiceLocator.GetInstance？

私のコードではすべてが機能しているので、ばかげた質問に思えるかもしれませんが、Unityコンテナーにこの方法でシングルトンを登録しました_ambientContainer：

 _ambientContainer.RegisterType<Application.StateContext>(new ContainerControlledLifetimeManager());

ローカルフィールドの使用を避けるために、次を使用します。

get {
    return ServiceLocator.Current.GetInstance<Application.StateContext>();
}

getプロパティ内で、オブジェクトのインスタンスを取得します。このようにして、常に同じインスタンスを取得します（Application.StateContextはまだシングルトンです）、またはGetInstanceは新しいインスタンスを作成しますか？

代わりにローカルの_ambientContainerフィールドを使用する方が良いですか？

get {
    return _ambientContainer.Resolve<Application.StateContext>();
}

ありがとうございました。

c#dependency-injectioninversion-of-controlunity-container
14
zero51

ServiceLocatorタイプは CommonServiceLocator プロジェクトからのものであり、Unityアダプターを使用していると想定しています。この場合、GetInstanceはcontainer.Resolveを呼び出すため、両方行は同等です。

ここでソースを表示できます- http://commonservicelocator.codeplex.com/wikipage?title=Unity%20Adapter&referringTitle=Home

6
devdigital

コンポーネントとサービスが登録されているアプリケーション内に単一の場所があることが保証されなくなったため、コンテナーのインスタンスをコンシューマークラスに渡すことは一般的にはお勧めできません。 （ 構成ルート として知られています）。

クラスは、パブリックAPIで、理想的には コンストラクター引数として指定 で依存関係を記述する必要があります。これにより、コンテナーは、特定の型の解決を求められるたびにインスタンスを自動的に提供します（-と呼ばれるプロセス）。 自動配線）。

依存性注入 は通常 推奨される選択 ですが、常に適用できるとは限りません。このような場合、例で行っているように、 Service Locator を使用すると、次善のソリューションが クラスをその依存関係 。

結論として、依存性注入がオプションでない場合は、クラスがコンテナーを直接参照することを避け、代わりにサービスロケーターを介してコンテナーにアクセスするようにします。

19
Enrico Campidoglio

できれば、コンテナを（ab）使用する両方の方法を避ける必要があります。

ServiceLocatorはアンチパターンと見なされます 最新のアプリケーションアーキテクチャでは。

9
Sebastian Weber