2

私の質問は、実際の実装にはあまり関与せず、よりアーキテクチャ上の性質のものです。

私は WCF に基づいて API を構築しましたが、PL を BL から分離する方法を実際に決定することはできません。次のような最小限の実装のみを保持するように、サービスを薄くしました。

public TagItemResponse TagItem(TagItemRequest request)
{
   return (new ItemTagRequestProcessor()).GetResponse(request);
}

もちろん、最初の疑問は、RequestProcessors がどの層に属しているかということです。それらをファサードと呼ぶのは間違っていると思いますが、同時にプレゼンテーションとは何の関係もありません。今のところ、それでも PL に属していると判断しました。プロセッサ メソッドは、私の DTO (DataContracts) を入力として受け取り、要求メッセージを検証し (基本クラス)、認証し (基本クラス)、最終的に次のように単一の DTO 応答を返します。

protected override void Process(TagItemRequest request, TagItemResponse response, Host host)
{
    var profile = ProfileFacade.GetProfile(host, request.Profile);
    var item = ItemFacade.GetItemId(host, request.Item);
    var tags = new List<Tag>();

    foreach (var name in request.Tags)
    {
        var tag = TagFacade.GetTag(profile, name);
        ItemFacade.TagItem(item, tag);
        tags.Add(tag);
    }

    ItemFacade.UntagItem(item, tags);
}

ここで、自分のビジネス オブジェクトに 1 対 1 で関連付けられたファサード クラスが必要な理由を自問します。たとえば、hostDAO とプロセッサの間のレイヤーとして機能する HostFacade があります。ただし、保持するロジックはほとんどなく、DAO 呼び出しを処理するだけです。

public static Host GetHost(HostDTO dto)
{
   return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}

質問: プロセッサとファサードをマージすることもできますよね?

この件に関する多くの記事や本を読んだことがありますが、それでも「正しい」方法に落ち着くことができず、問題に直面するたびに別のアプローチを選択する傾向があります。正しいアプローチが存在するのだろうか。

f.exを見つけました。doFactory の例では、サービス実装内から直接 DAO クラスと通信しました。ほとんどの ServiceContract メソッドはいくつかのロジックを共有しているため、共有基本クラスでの使用に適しているため、私はそれがあまり好きではありません。

サービス内からファサードのみが呼び出される他の例も見つけましたが、これは非常にきめ細かいメッセージに対してのみうまく機能するようです。サービスへの呼び出し回数をできるだけ減らすために、私のメッセージは「ファット」で複合的です。私の余分な処理レイヤーが私の本当の問題のようです。

おそらく、WCF サービスを正しく階層化する方法について 1 つの答えはありませんが、私の本能に合致するか、この問題に新しい光を当ててくれる意見を持っている人がいるといいのですが。

ありがとう！

ジェフリー

4

1 に答える 1

3

まず、PL とは、永続層ではなく、プレゼンテーション層を意味すると思いますか?

階層化されたアプリケーション設計を実装する場合、主な問題は常に次のとおりです。上のレイヤーの実装に影響を与えずに、下のレイヤーの実装を置き換えることができるか。

これは通常、永続層によって最もよく示されます。たとえば、SQL Server 2008 から MySQL に切り替えると、永続化レイヤーが変更されます (もちろん)。しかし、ビジネス層の変更も必要ですか? たとえば、ビジネス層は、SqlClient によってのみスローされる SqlException インスタンスをキャッチしますか? 優れた設計では、ビジネス レイヤーをまったく変更する必要はありません。

ビジネス層とプレゼンテーション層の分離にも同じ原則が適用されます。

あなたの例でItemTagRequestProcessorは、プレゼンテーション層にあるべきではないと思います。まず、プレゼンテーションとは何の関係もありません。次に、リクエストを処理する実装はプレゼンテーション層には関係ありません。Web アプリケーションと比較するとTagItemResponse、クライアントへのプレゼンテーションは Web (プレゼンテーション) レイヤーの問題です。のインスタンスを取得するTagItemResponseことは、プレゼンテーション層の下の層の関心事です。

ビジネス レイヤーと永続化レイヤーの間にファサードを配置するかどうかを決定するのは困難です。私は通常、ファサードを実装しません。これは、余分な (通常は不要な) 間接レイヤーを追加するためです。また、永続層メソッドをビジネス層メソッドから直接呼び出しても問題はないと思います。同じ原則を考慮に入れれば、ビジネス層の実装に影響を与えずに永続化層の実装を変更できますか。

敬具、

ロナルド・ヴィルデンバーグ

于 2009-03-19T15:00:06.523 に答える