关于.NET Core是否应该支持WCF Hosting的争论

.NET Core是否应该支持Windows通信基础（WCF） Hosting？在许多人看来，这似乎是一个奇怪的问题；答案很明显……是？否？好吧，实际上，这个问题的正反双方都在为自己的立场激烈辩护。本文将分析这场争论，说明双方的论据。

争论变得如此激烈，以致于WCF for .NET Core项目成员Barry Dorrans不得不在1月份 暂停了有关这个问题的辩论 。我们将分析这场争论，从支持者的观点开始。

2016年，Jan Johansson发起了一个话题，让人们列出他们在使用而且希望出现在.NET Core中的WCF特性。正如下面的汇总表所示，开发人员实际上正在使用WCF的许多高级特性。

• 事务性队列编程模型
• “ 行为（Behaviors）”
• “绑定（Bindings）”
• “上下文（Context）”
• 基于契约的编程模型
• 契约行为
• 基于契约的编码模型
• “发现（Discovery）”
• “持久化服务（Durable services）”
• “端点行为（Endpoint Behaviors）”
• “可扩展性（Extensibility）”
• 可扩展模型
• “头（Headers）”
• 实例管理
• 拦截模式管道
• 用于检测和访问SOAP头的消息查看器
• 元数据互换
• MEX端点和MEX框架
• 命名管道
• Net.Pipe绑定
• Net.TCP绑定
• NetTcp（半双工）
• “操作行为（Operation Behaviors）”
• OperationContext
• 有序消息
• 队列服务
• 可靠性
• 安全性
• 使用ServiceModel.ServiceHost的自托管
• 服务行为
• System.Transactions
• 限流

注意，这些全都是WS-*或WCF特有的特性。例如，当他们说“可靠性”，他们实际上是说WCF支持WS-ReliableMessaging标准。

WCF现状

许多人都有这样的印象，就是WCF仅用于遗留代码。但实际上，有许多公司在积极投资WCF软件开发。下面是一些例子。

Oliver C. Lanz写道：

我举一个具体的业务案例，就是我们有一个有着几百万行代码的投资管理系统，服务器端目前托管在世界范围内大约200家保险公司和银行本地的MS Windows Server上。我们有大约100+种服务类型，在最大的部署中，有大约700到800个并发服务实例在运行。我们的产品推动着核心业务的关键部分。

我们客户的IT支出非常高。这也是我们希望在未来几年做出重大改善的地方。其中一部分内容是找到托管环境的替代方案。一个比较好的选择是Windows Nano或.NET Core on Linux。为了能够采用.NET Core（或Windows Nano），我们将失去WCF服务器端。

由于我们非常喜欢把WCF作为一种编程模型，我们无意重写我们的应用程序，除非将来的托管环境不再提供WCF服务器端。我们用了许多特殊的特性。要开始采用.NET Core，下面是一些重要的特性：

[...]

是的，我们会继续在.NET Core上构建WCF服务。

Niplar写道：

在过去的六年里，在我参与过的方案中（.NET领域），我们总是基于WCF处理方案的服务层（位于防火墙&内部网后面）。没有东西能像WCF那样为我们提供同样的灵活性和对不同通信渠道的支持。

因为没有明确的WCF支持，所以我一直在阻止把生产环境迁移到.NET Core。如果.NET Core不支持WCF服务器，我们就需要重写大量的基础设施代码；总之，最终是模拟WCF编程模型。

我参与过的最大的方案供300多家健康医疗机构使用，重写服务层和功能就是一项巨大的投资，就不用说面临的高风险了。

事实上，就是在那个方案中，我们曾希望找到一种方式，可以在新产品中统一服务器和嵌入式设备（Linux）的编程模型。在.NET Core上支持WCF服务（不只是客户端）会给我们带来非常大的帮助和成本节省，因为那就不需要两个开发团队了；而代之以一个比较大的、非常专注的团队。

Fernando Ferreira Diniz de Moraes写道：

我的情况和[Oliver C. Lanz]的非常相似，只是我的业务场景是销售网点系统。和他一样，我们把应用程序部署到世界各地的许多商店中。为了减少基础设施成本，我们也在寻找托管应用程序的替代方法。就像[Jan Johansson]所说的那样，随意部署WCF服务就很好，给我们带来了巨大的灵活性。

WCF在我们的应用程序中扮演着重要的角色：它基于一个插件架构，其中的插件主要是WCF服务，因此，插件之间的通信实际上是WCF调用。这方面的改变意味着我们必须重写/重新构思许多基础设施代码。

在我们的情况下，使用ServiceHost实例的自托管和基于契约的编程模型至关重要。我们的计划是，不仅要迁移现有的服务，还要创建新服务。

Websitewill补充道：

命名管道、事务性队列编程模型、严格（不是鼓励）基于接口的设计、安全特性、进程隔离、错误屏蔽，等等。

Pavel Dvorak甚至说WCF是他们使用.NET的原因：

完全支持在.NET Core包含服务器端“WCF”的观点。我们刚刚完成了另一个相当大的、几乎完全是服务器端的处理系统。起初，我们因为没有使用Microsoft/.NET承受了巨大的压力，主要是因为其他（开源）技术栈在用于“基于微服务的”（就像传统的Web服务）解决方案时所具备的相对优势。但是，WCF的优点，如严格基于契约的编程模型，特别是命名管道绑定，端点和绑定的灵活性（是的，声明式方法/可配置性是一个优势），安全性，工具如日志的可扩展性，在系统增长，需要扩展性、性能及可维护性时，这些优势非常关键，而且，管道代码真得非常少。很明显，下一步是恰当的容器化（我们一直等待Nano Server），总之，能够把系统移植到下一代运行时平台，而又不会对当前的质量造成任何损失。

在话题“Server side WCF #1200”中，你可以看到更多开发人员支持使用WCF开发的例子。

为什么最初不包含WCF Hosting？

和以前一样，一个答案是，那是个简单的人力问题。只有这么多开发人员，他们不可能什么都做。来自微软的Ron Cain解释说：

郑重声明，我们不是故意把缺失的.NET Framework WCF特性排除在.NET Core WCF之外。不如说，最初的目标是，在处理其他WCF关键任务特性之前，在.NET Core中支持所有现有的Windows Store WCF API（都是面向客户端的）的特性。为了让它可以跨平台，移植WCF的许多工作都涉及重新实现WCF所依赖的OS级库（如套接字层、加密等），或许，这有助于我们理解现状。因此，支持WCF特性通常要首先针对每个平台替换OS级的库。这也许有助于理解.NET Core不再提供WCF中的“W”。

这就是为什么从你那里听到什么特性最重要如此有价值的一个原因，因为那让我们可以更深入地探讨这样的问题，“在Linux上实现特性X需要什么库？在OS X上呢？”等等。请继续提出建议和具体的方案！

为什么不使用REST？

对于WCF，最常见的抱怨是它与ASP.NET WebAPI和REST存在冗余关系。对此，Jörg Lang回应道：

服务之间的消息很重要，在开发企业后端时，REST不会奏效。它缺少太多其他人提到的东西。因此，.NET Core当然应该支持事务、队列消息、命名管道、可扩展性。

因此，.NET Core必须以这种或另外一种方式提供那些东西。如果把它叫做WCF，我也不介意。也许，这是个修复某些WCF弱点的机会，如过于复杂的配置，代之以基于惯例的方法。

除了MSMQ或服务总线外，你还应该/必须支持其他消息框架。一般来说，支持AMQP应该会不错，包括各种消息模式。

Agustin M Rodriguez附和了那种想法：

WCF一直用于提供高质量可扩展的服务，利用跨网络事务（System.Transactions）提供可靠性。如果.NET Core不支持WCF，那么我们会失去太多通过广泛的WCF拦截器链获得的“免费”益处，包括日志、行为和上下文流。

在Scott Hurlbert看来，WCF的吸引力是它根本不需要使用HTTP：

Binding binding = new BasicHttpBinding();
IMySimplestService proxy = ChannelFactory<IMySimplestService>.CreateChannel(binding, new EndpointAddress( "http://localhost:8008/" ) );
proxy.Echo("Hello");

Catalin Pop同样关注WCF如何成为各种协议之上的抽象：

是的，有许许多多的框架，大的，小的，更“企业级的”或者更面向1337 h4x0r的，提供不同的选项和模式，有的严格，有的灵活……这就是问题所在……没有基线。

WCF应该帮助处理所有这些完全不同的选项，提供一种统一而抽象的通信框架，作为.NET开发的基线。

你希望使用二进制protocolX，而不是http，当然，你可以插入它。你希望使用Oauth2，而不是windows验证，当然，配置一个，你希望使用NServiceBus插入NServiceBus绑定。你希望以某种形式转换上下文，如网络事务范围，你也可以把那个插入。应用程序编程模型保持不变。

从.NET应用程序的角度来看，RPC本身并不是一个复杂的东西，你调用一个方法或者接收一个调用。使其变得复杂的是众多方法和框架，以及你可以在其中实现的安全性、格式、特性和其他选项。

这些地方应该引入WCF，那是WCF的长项。

“WCF太复杂”

对于WCF，一种常见的批评是太复杂。公平地讲，它经常以一种非常复杂的方式实现。但是，就像Scott Hurlbert所指出的那样，不一定必须那样。下面是一个完整的WCF客户端和服务器所需的代码。

[ServiceBehavior]
public class MySimplestService : IMySimplestService
{
    public string Echo( string pInput )
    {
        return $"I heard you say: {pInput}";
    }
}

[ServiceContract]
public interface IMySimplestService
{
    [OperationContract]
    string Echo( string pInput );
}

var myServ = InProcFactory.CreateInstance<MySimplestService,
IMySimplestService>();
Console.WriteLine( myServ.Echo("Hello World") );

Binding binding = new BasicHttpBinding();
IMySimplestService proxy = ChannelFactory<IMySimplestService>.CreateChannel( binding, new EndpointAddress( "http://localhost:8008/" ) );
proxy.Echo("Hello");

注意，甚至是这其实都比你需要的东西多。如果你在使用一个代理生成器，那么服务类可以作为自己的服务契约，而不需要一个单独的接口。

反对WCF的机会成本论据

Blake Niemyjski总结了反对WCF的真正理由：机会成本和过去糟糕的体验：

我认为，创建服务器端WCF的投入是不值得的，应该优先考虑类似SignalR这样的工具。WCF客户端配置总是那么困难，我讨厌它:(，如果我错了，请帮我纠正……但是，为什么Web API不是要选择的方法……它是轻量级的，而且能给你构建应用所需要的所有东西，从任何平台只需要一个简单的调用即可……

把安全、事务、发布/订阅留给实现者……

还有其他几位开发人员也赞同“WCF与VB.NET”不值得投入。（这些争论似乎把WCF和VB.NET看作是相同的主题。）不过，Catalin Pop不同意这种观点：

[把安全、事务、发布/订阅留给实现者……]是任何人都能给出的最糟糕的建议。安全永远不应该留给实现者，那从来都是最糟糕的安全漏洞的源头……安全专家真得很少，或者说，很少有开发人员有能力恰当地实现安全细节，这项工作是由不足1%的程序员完成的。

服务器端WCF情况如何？

早在去年6月，Jeffrey T. Fritz写道：

有非常多的是WCF团队，我们正致力于开发可以确保兼容Windows 10、Windows Server和Windows容器的特性。

在Build大会上，我们做了一次非常成功的演示，第一次展示了我们的Windows容器。该领域的工作还在进行中，我们计划继续这些领域的投入。

WCF for .NET Core是我们重点关注的，我们正在和ASP.NET Core团队合作，优先进行这项工作。在可以公开发布的时候，我们会分享更多细节。

虽然WCF所需的部分底层库已经移植到了.NET Core，并且/或者添加到了.NET Stardard，但是，WCF Hosting本身并没有实际的进展。在3月份，一个题为“ 请做决定：服务器端WCF ”的独立话题被创建，并且打上了.NET 3.0里程碑的标签。

特别是最近，Immo Landwerth写道，“我们不会在.NET Core 3.0的时间框内引入[……]WCF Hosting，但是，我们稍后会根据用户的反馈来做。”

GitHub提供了 WCF的源代码 ，遵循MIT开源许可协议。因此，理论上讲，由社区支持的WCF for .NET Core版本是可行的。

查看英文原文： The Argument for WCF Hosting in .NET Core