サービスロケーターパターンを使用するDDDデータレイヤーを備えたフレームワークがあります。ServiceLocatorただし、現在、すべての参照を格納するグローバル静的クラスを使用しています。これを、クラスがインターフェイスを実装し、グローバル静的クラスIServiceProviderを削除する正しい実装にリファクタリングしたいと思います。ServiceLocator
IServiceProvider現在、エンティティクラスを除いて、ほとんどすべての場所で、インターフェイスを使用して既存のクラスを拡張することは問題ではありません。問題は、エンティティクラスを実装する必要があるのは非常に奇妙だと思うことIServiceProviderですが、IoCコンテナを介してリポジトリを解決できるようにするには、サービスプロバイダーにアクセスする方法が必要です。
IServiceProviderエンティティに実装せずにサービスロケーターパターンを実装するための最良の方法は何でしょうか？
Service Locator は、Unity、Castle Windsor、NInject などの Inversion of Control コンテナーと組み合わせて使用するのが最適です。Unity で動作するサービス ロケーターの例については、http://commonservicelocator.codeplex.com/wikipage?title= Unity%20Adapter&referringTitle=Home&ProjectName=commonservicelocator を参照してください。
また、Service Locator はアンチパターンと見なされる可能性があることに注意してください。非常に慎重に使用する必要があります。代わりに、コンストラクターまたはプロパティ インジェクションを使用する方がはるかに優れています。ただし、依存関係が実行される機能に大きく依存している場合は、Service Locator が役立ちます。
一体なぜエンティティ (ビジネス オブジェクト) が IServiceProvider を公開するのでしょうか? これはビジネス オブジェクトであり、サービスではありません。また、IServiceProvider はサービス用ではなく、サービス プロバイダーを公開するための IOC メカニズムです。
どちらかといえば、ORM / ビジネス オブジェクト フレームワーク / ランタイムはサービス プロバイダーですが、個々のエンティティではありません。
質問に戻させてください。エンティティが IServiceProvider を最初に公開するという賢明なプログラミングの概念は見当たりません。
- -アップデート
サービスはサービスロケーターのみを提供する必要があります-そしてあなたはそれを持っているべきです。定義されたスレッドが要素にアクセスする場合 (名前: UI など - UI 要素は、UI スレッドによる仕様によってアクセスする必要があります) には、スレッド静的変数を使用できます。これにより、グローバル シングルトンが壊れます。