問題タブ [service-locator]

asp.net mvc3でUnityを使用するためのいくつかのチュートリアルで、このコード行を見てきました。Service Locatorはアンチパターンであり、ベストプラクティスではないという印象を受けました。このServiceLocatorは、定義されたアンチパターン以外のものですか、それともこのコード行/この実装は悪い習慣と見なされていますか？

サービスロケーターパターンを使用するDDDデータレイヤーを備えたフレームワークがあります。ServiceLocatorただし、現在、すべての参照を格納するグローバル静的クラスを使用しています。これを、クラスがインターフェイスを実装し、グローバル静的クラスIServiceProviderを削除する正しい実装にリファクタリングしたいと思います。ServiceLocator

IServiceProvider現在、エンティティクラスを除いて、ほとんどすべての場所で、インターフェイスを使用して既存のクラスを拡張することは問題ではありません。問題は、エンティティクラスを実装する必要があるのは非常に奇妙だと思うことIServiceProviderですが、IoCコンテナを介してリポジトリを解決できるようにするには、サービスプロバイダーにアクセスする方法が必要です。

IServiceProviderエンティティに実装せずにサービスロケーターパターンを実装するための最良の方法は何でしょうか？

数か月以内に、アプリケーションを水平に分割する必要があります。アプリケーション内に CPU とメモリの負荷を必要とする特定のサービスがあり、スケーラビリティのために、複数の JVM 間でサービスを分割したいと考えています。

パーティション化する必要があるサービスをカプセル化する EAR があります。これを行う場合、サービス (UI など) のクライアントは、サービスの特定のインスタンスに対処できる必要があります。たとえば、Account という名前のサービスがあるとしますが、実際にはそのサービスの 3 つのインスタンスが 3 つの異なる JVM で実行されています (ただし、すべて同じ Java EE ドメインにあります)。アカウント ID から特定の VM にマップできる Service Locator があると仮定すると、その特定のアカウントにサービスを提供できる EJB にどのようにアクセスすればよいでしょうか?

考えられる解決策は、アプリケーション コンテナが別のアプリケーションの EJB に与える JNDI 名を利用することです。モジュールを異なる名前で 3 回デプロイすると、JNDI ルックアップを実行してそれらにアクセスできます。

java:global/AccountServer1/AccountFacade

java:global/AccountServer2/AccountFacade

java:global/AccountServer3/AccountFacade

これを機能させるには、依存性注入を使用して AccountFacade にアクセスすることはできません。AccountID を取得して Account アプリケーションの 1 つにマッピングできる AccountLocator EJB を使用する必要があります。巧妙になりたい場合は、メソッドへの引数が使用するサーバーを識別できると仮定して、ルックアップを透過的に行う「ローカル」アカウント ファサードをおそらく実装できます...

このアプローチは実行可能ですか? より良い代替手段はありますか？

Mark Seemannの「Dependency Injection in .NET」を読んだ後、アンチパターンであるService Locatorには近づきません。

MVC 4 のリリース ノートを読むと、次のように表示されます。

DependencyResolver による制御の反転 (IoC) の改善: Web API は、MVC の依存関係リゾルバーによって実装されたサービス ロケーター パターンを使用して、さまざまな機能のインスタンスを取得するようになりました。

したがって、Microsoft が 2012 年にサービス ロケーターを使用する理由について、私は好奇心と混乱を覚えています。

global.asax の Application_Start メソッドで Solr への接続を設定しています。Startup.Init<ApartmentDoc>("http://localhost:8080/solr");

Solr サーバーへの呼び出しを行うために使用しようとしている DAO ライブラリ プロジェクトがあります。問題は、ライブラリ クラスから solr 接続のインスタンスにアクセスしようとすると、ServiceLocator.Current で null 参照例外が発生することです。

私はDIとSolrNetを初めて使用するので、助けていただければ幸いです。

ありがとう、ドリュー

タイプ別に ServiceLocator (MEF) から値を取得しようとしています。

例: タイプが DMControl であるすべてのコントロールを与える

リストが空です。ServiceLocator からリストを開くと、そのようなコントロールがあります。エクスポート キーを使用して DMControl のインスタンスを取得した場合も機能します。1 つのタイプのすべてのコントロールを取得できないのはなぜですか?!

一般に、メソッドを使用してクラスをインスタンス化し、フィールドやプロパティを使用しない場合、多くのオーバーヘッドが発生しますか?

コンストラクター インジェクションを多用する ASP.NET MVC アプリケーションを開発しており、一部のコントローラーにはこれまでに最大 10 個の依存関係があります。しかし、依存関係の数が多いためIMyAppServiceProvider、MVC 3 の DependencyResolver を介して、すべての依存関係への汎用アクセスを提供するインターフェイスとクラスに頼りました。

アプリケーション固有のコードをすべて取り除き、基本的なセットアップでGistを作成しました (これには、以下で説明する BaseController のセットアップは含まれません)。

を受け入れる BaseController クラスも作成しましたIMyAppServiceProvider。すべてのコントローラーは、この基本クラスから継承します。基本クラスはIMyAppServiceProviderオブジェクトを受け取り、さまざまなサービスすべての変数を保護しています。コードは次のようになります。

これにより、コントローラーのコードが「きしむようにきれい」になります。プライベート/保護された変数、コンストラクターでの割り当てはなく、サービスは基本クラスの保護された変数によって参照されます。 ただし、特定のコントローラーがそれらすべてを使用するかどうかに関係なく、すべての要求は、アプリケーションが使用するすべてのサービスをインスタンス化します。

私のサービスは単純で、いくつかのビジネス ロジックとデータベースのやり取りを伴うメソッド呼び出しだけが含まれています。これらはステートレスであり、クラス フィールドやプロパティはありません。したがって、インスタンス化は高速である必要がありますが、これがベスト プラクティスであるかどうか疑問に思っています (これは用語の定義です)。

コードを書くとき、オブジェクトの 2 つの大きなグループを識別できるはずです。

• 注射剤
• ニューエイブル

http://www.loosecouplings.com/2011/01/how-to-write-testable-code-overview.html

http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

• 注入可能オブジェクトは、コンストラクターで依存関係を公開するオブジェクト (サービス) です。これらの依存関係は通常、IoC コンテナーを使用して解決されます。これらのオブジェクトは、コンストラクターで他の注入可能オブジェクトのみを要求できます。

• Newable はコンストラクターで依存関係を公開するオブジェクトですが、newable は他の newable オブジェクト (エンティティ、値オブジェクト) のみを要求できます。newable オブジェクトのもう 1 つの特徴は、注入可能なオブジェクトへの参照を保持してはならないことです。

しかし、コードを書くとき、多くの場合、サービス (注入可能) をエンティティ (新規可能) に「注入」する必要があります。

newable オブジェクトでサービスの依存関係を公開する方がメソッド レベルで行うほうがよいのではないかと考えていましたが、これはやるべきことがたくさんあるように思えます....メソッドが呼び出されるたびに依存関係を解決することを考えているだけです... . これは、Service Locator アンチパターンを使用する必要があるように思えます。

私がこれを解決した方法は次のとおりです。

• 依存関係を公開するメソッドを使用してインターフェイスを作成します (サービスはこのメソッドで使用されます)

• インターフェイスの拡張メソッドを作成し、別の名前空間、おそらく別のアセンブリに配置し、サービス ロケーターを使用して依存関係を解決する元のメソッドへの呼び出しをラップするだけです。

これを行うことで、newable オブジェクトと注入可能オブジェクトを一貫して分離し、newables でサービスを簡単に使用できるようになります。

• どう思いますか？
• 拡張メソッドでサービス ロケーターを使用することは悪い習慣と見なされますか?
• 拡張メソッドの呼び出しをどのように単体テストしますか?

この質問は、プログラマー スタックにより適している可能性があります。もしそうなら、私はそれを移動します。しかし、ここでもっと多くの答えが得られると思います。

これまでのところ、ドメイン内のすべてのインターフェイスの依存関係は、実行中のアセンブリからの DI を使用して解決されています。これは、現時点では .NET MVC3 プロジェクト (+ Unity IoC コンテナー) です。ただし、サービスロケーターの方が適していると思われるシナリオに出くわしました。

URL からのコンテンツを格納 (キャッシュ) するエンティティがドメイン内にあります。具体的には、メタデータ URL から SAML2 EntityDescriptor XML を格納します。単一のメソッドを持つインターフェイス IConsumeHttp があります。

現在の実装では、System.Net の静的 WebRequest クラスを使用しています。

XML コンテンツをキャッシュするエンティティは、はるかに大きなエンティティ集約内の非ルートとして存在します。集約の残りの部分については、MVC コントローラーのパブリック エンドポイントであるやや大きな Facade パターンを実装しています。次のように、ファサード コンストラクターに IConsumeHttp 依存関係を挿入できます。

これで私が目にする問題は、ファサード内の 1 つのメソッドだけがこのインターフェースに依存しているため、ファサード全体にそれを注入するのはばかげているように思われることです。クラスのオブジェクト作成によってWebRequestHttpConsumer多くのオーバーヘッドが追加されることはありませんが、ドメインはこれを認識していません。

代わりに、エンティティのすべてのキャッシュ ロジックを別の静的ファクトリ クラスに移動することを検討しています。それでも、コードは に依存しIConsumeHttpます。そのため、静的ファクトリ メソッド内で静的サービス ロケーターを使用して IConsumeHttp を解決することを考えていますが、キャッシュされた XML を初期化または更新する必要がある場合のみです。

私の質問: これは悪い考えですか? XML メタデータが適切にキャッシュされていることを確認するのは、ドメインの責任であるべきだと私には思えます。ドメインは、他の関連操作 (SAML Authn 要求と応答のメタデータの取得、SAML EntityID またはメタデータ URL の更新など) の一部として定期的にこれを行います。それとも私が気にしすぎているだけでしょうか？

LightCoreをデフォルトのサービスロケーターとしてMetadata-/ORM-Frameworkに統合しようとしています。したがって、フレームワーク内からいくつかのデフォルトの登録を行い、フレームワークユーザー（=アプリケーション開発者）が自分の実装で何らかの形で「却下」できるようにします（これを行うのが好きな場合）。これは、LightCore IoCコンテナーまたは他のIoCコンテナーでどのように行う必要がありますか？

私たちが試したこと：

Fooの契約として2つのクラスを登録しました。上記のコードでは、常に最初の（Fooのインスタンス）が返されます。したがって、ここでの支配はありません。ところで：Foo2のインスタンスを取得したいと思います。

具象クラスの使用からインターフェースの使用に変更しました。

これを実行すると、Resolve <>（）でresolve例外が発生し、登録が見つからなかったことが通知されます。2番目の「Register（）」ステートメントを削除すると、Fooのインスタンスを取得する方法で機能します。

いくつかの一般的な概念を見逃したかどうかはわかりません。これは他のIoCでも同じように機能しますか？登録を無効にする/上書きするための推奨される方法は何ですか？

このトピックに関するヘルプは、LightCoreだけでなく素晴らしいものです。

更新： SimpleInjector IoCコンテナーを使用して、上記のシナリオのいくつかのテストを設定しました。このコンテナーでは、コンストラクターでAllowOverridingRegistration = trueを指定する必要があり、期待どおりに機能します。したがって、LightCoreはこのユースケースを正しくサポートしていないように見えますが、他のユースケースはサポートしています。

更新： LightCoreの作成者から、LigtCoreは登録のオーバーライドをまったくサポートしていないという迅速な回答がありました。したがって、これらのシナリオの登録をLightCoreでオーバーライドする方法はないように思われるため、LightCoreからSimpleInjectorに切り替えました。

次のSimpleInjector構成は、現在の4つの要件に一致します。

乾杯、マーク