分层WCF服务的正确方法 [英] Layering a WCF Service the right way

问题描述

我的问题更多的是一种建筑的性质，较少涉及的实际执行情况。

My question is more of an architectural nature, less involved with the actual implementation.

我必须建立一个基于WCF的API，而不能真正决定如何在PL从BL分开。我已经作出了服务薄，所以它只能容纳最小的实施，是这样的：

I have build an API based on WCF, but can't really decide on how to separate the PL from the BL. I have made my service thin, so that it holds only a minimum of implementation, something like:

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

当然比第一个问题是，在做了RequestProcessors属于哪一层？我认为这是错误的打电话给他们一个门面，但在同一时间，他们什么都没有做与presentation。至于现在，我决定了他们在PL仍然归属。该处理器的方法把我的DTO的（DataContracts）作为输入，验证请求消息（基类），验证（基类），并最终返回一个DTO的反应，就像这样：

Than of course the first question arises, in what layer do the RequestProcessors belong? I think it would be wrong to call them a facade, but at the same time, they have nothing to do with presentation. As for now, i decided that they nevertheless belong in the PL. The processor methods take my DTO's (DataContracts) as input, validate the request message (base class), authenticate (base class) and eventually return a single DTO response, like so:

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呼叫。

Now I ask myself, why do i need the facade classes 1:1 related to my business objects. For example i have a HostFacade that acts as a layer between the hostDAO and the processors. It, however, holds very little logic, it merely handles the DAO calls.

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

问：我还不如合并处理器和外墙，右

Question: I might as well merge the processors and the facades, right?

我读过关于这个问题的许多文章/书籍，但我仍然无法安定在'正确'的路要走，往往每一次我面临的问题时选择了不同的方法。我不知道一个正确的做法，甚至存在。

I've read many articles/books on the subject, but i still can't settle on the 'right' way to go and tend to chose a different approach every time i face the issue. I wonder if a right approach even exists.

我发现f.ex.在doFactory例子，他们聊到了DAO类从服务实现中的权利。我真的不喜欢的，因为大多数的ServiceContract方法分享一些逻辑，因而能够很好的与共享的基类使用。

I've found f.ex. the doFactory example, where they talked to the DAO classes right from within the service implementation. I don't really like that, as most ServiceContract methods share some logic, and thus lend themselves well for use with shared base classes.

我还发现其他的例子，只有外墙是从服务中调​​用，但似乎只有好非常细粒度的信息工作。我的消息是脂肪和复合，以减少呼叫尽可能的服务的数目。我的额外处理层似乎是我的真正的问题。

I've also found other examples where only the facades are called from within the services, but that seems to work well only for very fine-grained messages. My messages are 'fat' and composite in order to reduce the number of calls to the service as much as possible. My extra processing layer seems the be my real problem.

大概没有一个统一的答案，如何正确地层WCF服务，但希望有一些你在那里有自己的见解，这将既符合我的直觉或阐明了我的问题的一些新的见解。

Probably there is no single answer as to how to correctly layer a WCF service, but hopefully there are some of you out there with an opinion that will either conform my instincts or shed some new light on the subject for me.

感谢名单！

杰弗里

推荐答案

首先，我认为通过PL你的意思是presentation层，而不是持久层？

First, I assume that by PL you mean presentation layer, not persistence layer?

在实施分层应用程序设计，主要的问题应该永远是：我可以代替下层执行不影响上面的层（S）的实施

When implementing a layered application design, the main question should always be: can I replace the implementation of a lower layer without impacting the implementation of the layer(s) above.

这通常是最好的持久层所示。如果从SQL Server 2008中切换到MySQL为例，持久层的变化（当然）。但也需要在业务层的变化？举例来说，难道只能由SqlClient中抛出的业务层的SQLException抓实例？在一个良好的设计，业务层的需求都没有改变。

This is usually best illustrated by the persistence layer. If you switch from SQL Server 2008 to MySQL for example, the persistence layer changes (of course). But are changes in the business layer also necessary? For example, does the business layer catch SqlException instances that are only thrown by SqlClient? In a good design, the business layer needs no changes at all.

同样的原则应适用于业务层和presentation层之间的距离。

The same principle should apply to the separation between business layer and presentation layer.

在你的榜样，我要说的是， ItemTagRequestProcessor ​​不应该在presentation层。首先，它有无关presentation，第二，处理请求的实施不是为presentation层的关注。与Web应用程序进行比较，presenting一个 TagItemResponse 到客户端是网络（presentation）层的关注。检索 TagItemResponse 的一个实例是presentation层下面的层的关注。

In your example, I would say that the ItemTagRequestProcessor should not be in the presentation layer. First, it has nothing to do with presentation, second, the implementation of processing a request is not a concern for the presentation layer. Compare it with a web application, presenting a TagItemResponse to a client is the concern of the web (presentation) layer. Retrieving an instance of TagItemResponse is the concern of a layer below the presentation layer.

决定是否有你的业务层和持久层之间的门面是困难的。我通常因为它增加了额外的间接（通常是不必要的）层没有实现门面。此外，我没有看到直接从业务层的方法调用持久层的方法有问题。只要你采取同样的原则考虑：你可以改变持久层实现，而不会影响业务层执行

Deciding whether to have a facade between your business layer and persistence layer is difficult. I usually do not implement a facade because it adds an extra (usually unnecessary) layer of indirection. Besides, I do not see a problem in calling persistence layer methods directly from business layer methods. If only you take the same principle into account: can you change the persistence layer implementation without affecting the business layer implementation.

亲切的问候，

罗纳德Wildenberg先生

Ronald Wildenberg

这篇关于分层WCF服务的正确方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！