この質問は、プログラマーズスタックの方が適切かもしれません。もしそうなら、私はそれを動かすでしょう。しかし、私はここでより多くの答えを得るかもしれないと思う。ドメインクラスでサービスロケータパターンを使用することは時々大丈夫ですか？
これまでのところ、私のドメイン内のすべてのインターフェイス依存関係は、実行中のアセンブリからDIを使用して解決されています。これは現在、.NET MVC3プロジェクト（+ Unity IoCコンテナ）です。しかし、私はサービスロケータがより良い選択かもしれないと思うシナリオを走ってきました。
URLにコンテンツを格納（キャッシュ）するエンティティがドメイン内にあります。具体的には、SAML2 EntityDescriptor XMLをメタデータURLから格納します。私は、単一のメソッドとのインタフェースIConsumeHttpを有する：
public interface IConsumeHttp
{
string Get(string url);
}
現在の実装では、System.Net静的WebRequestクラスを使用する：
public class WebRequestHttpConsumer : IConsumeHttp
{
public string Get(string url)
{
string content = null;
var request = WebRequest.Create(url);
var response = request.GetResponse();
var stream = response.GetResponseStream();
if (stream != null)
{
var reader = new StreamReader(stream);
content = reader.ReadToEnd();
reader.Close();
stream.Close();
}
response.Close();
return content;
}
}
XMLコンテンツをキャッシュエンティティが非ルートとして存在しますはるかに大きなエンティティ集合体である。残りの集計では、MVCコントローラのパブリックエンドポイントであるやや大きなFacadeパターンを実装しています。私はそうのようなファサードのコンストラクタでIConsumeHttp依存性を注入できます。
public AnAggregateFacade(IDataContext dataContext, IConsumeHttp httpClient)
{
...
私はこれを見問題はファサードで唯一の方法は、このインターフェイスに依存しているということなので、ためにそれを注入する愚かなようです全面ファサード。 WebRequestHttpConsumerクラスのオブジェクトの作成でオーバーヘッドが増えることはありませんが、ドメインはこれを認識しません。
代わりに、エンティティのキャッシングロジックをすべて別の静的ファクトリクラスに移動することを検討しています。それでもコードはIConsumeHttpに依存します。だから私はIConsumeHttpを解決する静的なファクトリメソッド内の静的なサービスロケータを使用することを考えていますが、キャッシュされたXMLを初期化またはリフレッシュする必要があるときだけです。
私の質問：これは悪い考えですか？ XMLメタデータが適切にキャッシュされていることを確認するのは、ドメインの責任である必要があります。ドメインは、SAML Authn要求のメタデータ（&レスポンス、SAML EntityIDまたはメタデータURLの更新など）を他の関連操作の一部として定期的に実行します。それともあまりにも心配していますか？
関連：http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-objec – Steven
これは有効な質問ですそう。 – Steven
@Stevenはあなたのアーキテクチャのクエリー+コマンド面をどのようにロールしているかについてのリンク、信頼の投票、そしてあなたのブログを感謝します。非常に面白いもの。 – danludwig