問題タブ [service-locator]

CommonServiceLocatorを使用するようにコードをリファクタリングしようとしています。他のコンポーネントで使用されている共有ライブラリがあります。

私が理解していないのは、これらのコンポーネントはServiceLocator.Currentを呼び出して、それらのタイプを解決することになっているのでしょうか。その場合、ServiceLocator.Currentが実際に設定されていることを確認するにはどうすればよいですか？独自の「MyServiceLocator」を作成して静的コンストラクターを追加する必要がありますか？（それは標準化された抽象化を持つという目的を打ち負かすようです）

または、共有ライブラリに、解決可能なすべてのタイプをパブリックプロパティとして公開し、ServiceLocatorを共有ライブラリの内部に完全に保持するクラスを含める必要がありますか？（これは、抽象化の上に抽象化の上に抽象化があることを意味します）？

重要なのは、コンポーネントはDIを介して作成されておらず、必要なものを取得するためにコンテナを呼び出すことになっているということです。

asp.net mvc 3 と .net-4 を使用する単純なアプリケーションの場合、パフォーマンスの問題を考慮して、どのサービス ロケータ アプリケーションが優先されますか?

そのため、アプリケーションからサービスロケーターを削除する方法について説明を求めています。

どのビューがアクティブで、どのビューが開いているかを認識し、新しいビューを作成するViewManagerServiceがあります。

現在、私のViewModelは、コンストラクターインジェクションを介してIViewManagerServiceをインジェクトします。これらのViewModelは、呼び出されたときに呼び出しを行うことができるICommandを公開します。

次に、ViewManagerServiceはサービスロケーターを使用して、キー「MyCoolView」を使用して新しいビューを検索およびインスタンス化します。キー文字列を使用する理由は、ViewをViewModelsから切り離すことができるようにするためです。ViewManagerServiceを他のアプリで使用できるように十分に汎用性を維持したいので、特定のIAbstractFactoryインターフェイスに依存させたくありません。

ヒント/提案はありますか？

次のコードを考えると、次のパターンにならなければならないのはコードの匂いですか?

モデル:

Product を編集するためのビュー:

カテゴリの EditorTemplate

HtmlHelper メソッド

参考までに、ヘルパー メソッドの実際の実装では、DataTextField と DataValueField の名前、選択された値などを取得するためにいくつかのラムダが必要です。

気になる点は、HtmlHelper 内で servicelocator を使用していることです。Product モデルに AllCategories プロパティが必要だと思いますが、必要になるたびにコントローラーに値を設定する必要があります。

したがって、ヘルパー メソッドは汎用的であるため、私が使用しているソリューションはより簡単だと思います (ここには含まれていないモデル バインダーも同様です)。したがって、DropDownList を必要とするタイプごとに EditorTemplate を作成するだけです。

何かアドバイス ？

これは、しばらくの間私を悩ませてきた問題です。私はこれらのパターンのいくつかについてまだかなり新しいので、用語のいずれかを間違って使用した場合は、私を許してください (そして私を修正してください)。

私の方法論

ゲームエンジンを作りました。私のゲーム エンジンのすべてのオブジェクトは、制御の反転を使用して依存関係を取得します。これらの依存関係はすべてプロトコルを実装しており、ブートストラップ フェーズ以外ではプロジェクト内で直接アクセスされることはありません。これらのオブジェクトを取得するために、サービス ロケーターの概念があります。サービス ロケーターの仕事は、特定のプロトコルに準拠するオブジェクトを見つけて返すことです。これはファクトリによく似ていますが、依存関係も処理する必要があります。

サービス ロケータにサービスを提供するために、サービス指定子と呼ばれるものがあります。サービス ロケータは、プロジェクト内のすべてのサービス指定子を認識しており、オブジェクトが要求されると、提供されたプロトコルに準拠するオブジェクトのインスタンスをそれぞれから取得しようとします。このオブジェクトは呼び出し元に返されます。このセットアップの素晴らしい点は、サービス指定子がサービス ロケーターについても認識しているため、依存関係がある場合は、サービス ロケーターにそれらの特定の依存関係を問い合わせるだけです。

例を挙げると、HighScoreManager というオブジェクトがあります。HighScoreManager は PHighScoreManager プロトコルを実装します。PHighScoreManager のインスタンスが必要な場合はいつでも、以下を呼び出して取得できます。

したがって、制御の反転。ただし、ほとんどの場合、これを行う必要さえありません。ほとんどのクラスはサービス指定子に配置されているためです。依存関係として PHighScoreManager が必要な場合は、サービス ロケータを通じて取得されます。したがって、私は制御の反転に対してフラットなアプローチをとっています。

私の問題

ゲーム エンジンのコードを共有したいので、スタティック ライブラリとしてコンパイルしました。これは他のすべての場合にうまく機能しますが、サービスロケーターでは少し扱いに​​くいようです. 問題は、一部のサービスがゲームごとに変更されることです。上記の例では、あるゲームのスコアは時間であり、別のゲームではポイントである可能性があります。したがって、HighScoreManager は、PScore オブジェクトの作成方法を指示する PHighScoreCreator のインスタンスに依存します。

PHighScoreCreator を HighScoreManager に提供するには、ゲームのサービス指定子が必要です。これを達成するために考えられる唯一の方法は、リフレクションの Cocoa バージョンを使用することでした。いろいろ調べてみたところ、クラスは NSBundle で発見できることがわかりましたが、現在のバンドルを取得する方法はないようです。したがって、サービス指定子を検索できるようにするには、ゲーム ロジックを独自のバンドルにコンパイルし、エンジンにこのバンドルを検索してロードさせる必要があります。これを行うには、エンジン コードとゲーム ロジック バンドルの両方を格納する 3 番目のプロジェクトを作成する必要がありますが、実際には、エンジンの静的ライブラリを使用するゲーム プロジェクトだけが必要です。

私の本当の質問

結局のところ、私の質問は

1. Cocoa Touch で達成しようとしていることを行うためのより良い方法はありますか、または
2. サービス指定子プロトコルに準拠するクラスをメイン バンドルから検出する方法はありますか?

質問を読んでくれてありがとう。

-らせん

MVVMパターンと単純なServiceLocator実装を使用していますが、問題が発生した場合、ビューが設計時に実行されているときにサービスをどのようにセットアップする必要がありますか？

Ivはこれを試しましたが、VS 2010などでは機能しないようです。古いコンピューターでは機能することはわかっていますが、新しいコンピューターでは機能しません。それで、誰かが良い代替案を知っていますか？

編集:(マーリン・モーガン・グラハムに代わって）

私がやろうとしているのはこれです。私の見解、ViewModel、およびサービスがあります。ここでの違いは、各サービスの2つの実装が設計時と実行時用にあることです。より良い説明については、こちらをご覧ください。

GF V3.01 サーバーにアプリがあり、EJB コンテナーにリモート メソッドがあります。リモート Swing アプリ プロセスからリモート メソッドを呼び出すと、実行に時間がかかります。ServiceLocator について読みましたが、リモート Swing アプリの例が見つかりません。誰か助けてください！リモートメソッド呼び出しを高速化するためのアイデアを提供してください。

このテストを作成し、これが有効なアプローチでない場合はコメントします

@Remote パブリック インターフェイス CountryManagerRemote は EJBHome を拡張します {

}

/** CountryManagerRemote の実装 */

@Stateless public class CountryManagerBean は CountryManagerRemote {

}

/** リモート Swing アプリのコード */ public class ClientApp {

}

/** リモート ejb の ServiceLocator */

パブリッククラスServiceLocator {

}

クラスが常にFooオブジェクトを作成するとは限らない場合、クラスをFooFactoryと呼ぶのは間違っていますか？たとえば、次のインターフェイスがある場合：

次のように実装します。

次に、このクラスは、IoCコンテナの構成方法に応じてFooを作成する可能性があります。'XxxFacotry'の名前を実際のファクトリ用に予約する必要がある場合、インターフェイスとクラスを何と呼ぶ必要がありますか？

明白な答えはIFooProviderですが、「XxxProvider」は使いすぎて曖昧すぎるため、避けたいと思います。一方、IFooServiceLocatorはあまりにも具体的です。

代替の命名提案は大歓迎です。

Unity DI と EntLib Service Locator を使用する小さなツールキットがあります。この問題は、サード パーティのアプリが EntLib サービス ロケータを使用しようとすると発生します。EntLib Service Locator はシングルトンのように見えるため、サードパーティ アプリがそのサービス ロケーターをブートストラップすると、サービス ロケーターの構成が消去されます。クライアントは、次の方法で Service Locator を作成します。

そして、次のように使用されます。

2 つの ServiceLocator を管理する方法や、実行時にサービス ロケーターに追加のコンポーネントを登録する方法はありますか?

ServiceLocationからコンテナインスタンスを取り戻すことは可能ですか？タイプのインスタンスを解決する機能のみが表示され、登録することはできません。