私の質問はアーキテクチャ上の性質であり、実際の実装にはあまり関係しません。WCFサービスの適切なレイヤー化
私はWCFに基づいてAPIをビルドしましたが、実際にBLからBLを分離する方法を決定することはできません。最初の質問が生じもちろんのより
public TagItemResponse TagItem(TagItemRequest request)
{
return (new ItemTagRequestProcessor()).GetResponse(request);
}
、何層にRequestProcessorsが所属ん：それは、実装の唯一の最小値、のようなものを保持しているように私は、私のサービスを薄くしていますか？彼らをファサードと呼ぶのは間違いだと思うが、同時に彼らはプレゼンテーションとは関係がない。今のところ、私は彼らにもかかわらず、PLに属していることを決めた。プロセッサの方法はそうのように、要求メッセージ（基底クラス）、認証（基本クラス）を検証し、最終的には単一DTO応答を返し、入力としての私のDTOの（DataContracts）を取る：
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つの答えはありませんが、私の本能に合致するか、または私のためにいくつかの新しい光を当てる意見がありましたらうれしく思います。
Thanx！
ジェフリー
PLとBL？それらの略語に精通していない人々は混乱しないように、より明確にしてください。 –
@ unforgiven3あなたは正しいです、私は明示的にプレゼンテーションレイヤー（PL）、ビジネスレイヤー（BL）とデータレイヤー（DL）を書かなければなりません。私は、文脈（アーキテクチャ上の質問）が返答できる人を理解すれば、それを仮定した。とにかく、ポイントを取った。 –