.net - WCF 是为 .NET 客户端托管复杂类库的正确架构服务选择吗？

Question

我正在尝试将一个相当复杂的类库作为服务公开，我认为 WCF，但是非常环保，并且正在努力理解我在架构上能做什么和不能做什么。如果我的客户也是 .NET(比如说 WinForms、WPF 和/或 ASP.NET MVC3)，那么编写一堆契约(Contract)来重新公开公共(public)类或序列化复杂对象似乎有点过头了。从那里的许多教程中很难知道，因为其中很多只适用于值/原始类型。

WCF是要走的路吗？如果是这样，如果类库将管理数据的所有方面并且只公开对象，那么哪种风格最容易实现？

一个简单的类比:a HumanBody需要作为服务公开的类，允许多个用户，始终开启等。如果我有一个 .NET Applause 客户端，我想做类似的事情

ServiceName.HumanBody myBody = new HumanBody();
myBody.Parts.Hands.Clap();  

我必须将这些对象转换为接口(interface)并编写一堆包装器方法，但这些对象是“完整的”，因为它们存在——这就是为什么我觉得它有点矫枉过正。 (我知道我没有正确考虑这个问题——这就是问题的原因。如果这些问题太模糊，我会改进评论/答案。)

(另外，请注意，我并不是在问如何实际完成这个问题——这个问题已经有很多版本了，有几个值得注意的好答案 here 和 here 。还有一个非常有用的教程关于如何构建您自己的 WCF 架构，而不使用 VS 自动添加的困惑 here。我正在自己完成构建。)

Answer 1

WCF 很可能是最适合您的途径。但是，在您开始考虑如何处理它之前，我认为我们需要稍微澄清一下服务是什么。

一项服务，无论它使用何种传输层(HTTP、HTTPS、TCP、UDP、MSMQ、运营商 pidgeons 等)，都只是一个接受参数的操作列表。就其本身而言，您不能将“HumanBody”类作为服务公开。服务不是面向对象的；它们非常像程序化编程。

当然，您可以将复杂的对象图作为参数发送，或者将它们作为服务操作的返回值返回。您还可以编写您的客户端库，使您的服务接口(interface)是面向对象的，但您的实际服务命令不会这样。

要使用上面的示例，您可以将其作为服务接口(interface):

public interface IHumanBodyService
{
    ClapHands(<parameters>);
}

<parameters>这里将是发送到服务所需的任何识别信息，以便它知道要做什么。这可能是整个 myBody对象图(当然是序列化的，但是只要您的类被正确注释，WCF 就会为您处理)，或者它可能像 BodyId 这样简单或 PersonId值(value)。