【发布时间】：2010-10-14 06:36:51
【问题描述】：
我的问题更多的是架构性质，较少涉及实际实现。
我已经构建了一个基于 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 与我的业务对象相关的外观类。例如，我有一个 HostFacade，它充当 hostDAO 和处理器之间的层。然而，它包含的逻辑很少，它只处理 DAO 调用。
public static Host GetHost(HostDTO dto)
{
return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}
问题：我不妨合并处理器和外观，对吗？
我已经阅读了许多关于该主题的文章/书籍，但我仍然无法确定“正确”的方式，并且每次遇到问题时都倾向于选择不同的方法。我想知道是否存在正确的方法。
我找到了 f.ex。 doFactory 示例，他们直接从服务实现中与 DAO 类进行对话。我不太喜欢这样，因为大多数 ServiceContract 方法共享一些逻辑，因此很适合与共享基类一起使用。
我还发现了仅从服务中调用外观的其他示例，但这似乎仅适用于非常细粒度的消息。我的消息是“胖”和复合的，以尽可能减少对服务的调用次数。我的额外处理层似乎是我真正的问题。
对于如何正确分层 WCF 服务可能没有单一的答案，但希望你们中的一些人的意见可以符合我的直觉或为我在这个主题上提供一些新的见解。
谢谢！
杰弗里
【问题讨论】：
-
PL 和 BL？请说得清楚一点，以免不熟悉这些首字母缩写词的人感到困惑。
-
@unforgiven3 你是对的，也许我应该明确地编写表示层 (PL)、业务层 (BL) 和数据层 (DL)。我只是假设，考虑到能够回答的上下文（架构问题），人们会理解。无论如何，要点。
标签： c# wcf architecture n-tier-architecture