1

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

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

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

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

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

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

4

2 に答える 2

0

XMLメタデータが適切にキャッシュされていることを確認するのは、ドメインの責任であるように思われます。

あなたのドメインが本当にメタデータ操作やhttpリクエストなどに関するものでない限り、それについてはよくわかりません。非技術ドメインを持つ「通常の」アプリケーションの場合、インフラストラクチャ/技術サービス層でのキャッシュの問題に対処したいと思います。

これで私が目にする問題は、ファサード内の1つのメソッドのみがこのインターフェイスに依存しているため、ファサード全体にそれを注入するのはばかげているように見えることです。

明らかに、ファサードは多くの依存関係を自然に指す傾向があるため、通常、コンストラクターの注入にはあまり適していません。他のタイプの注入を検討することも、ご指摘のとおり、ロケーターを使用することもできます。しかし、私が個人的に行うことは、ファサードが本当に適切かどうかを自問し、すべてのコントローラーで同じ大きなインターフェイスの代わりに、よりきめの細かいオブジェクトを使用することを検討することです。これにより、大規模なオブジェクトを前もって膨らませるのではなく、モジュール性とアドホックな注入が可能になります。

しかし、それは私がファサードの大ファンではないからかもしれません;）

于 2012-03-22T13:41:16.203 に答える
0

@ ian31 へのコメントで、「ドメインに正しい XML があることをコントローラーに確認させるのは細かすぎて、クライアントに責任を与えすぎているようです」と述べています。このため、コントローラーがそのサービス/リポジトリ (キャッシュ層を実装できる) に正しい & 現在の XML を要求することをお勧めします。私にとって、この責任はドメイン エンティティに求められるものです。

ただし、概説した責任に問題がなく、オブジェクトの作成がそれほどオーバーヘッドではないことに言及している場合は、エンティティに IConsumeHttp を残しても問題ないと思います。
この責任に固執する別の方法として、このインターフェイスを子エンティティに移動することもできます。これが可能だった場合、少なくとも依存関係はそれを必要とするシナリオに限定されます。

于 2012-03-27T03:42:30.713 に答える