asp.net-mvc - 强大的自托管服务器的最佳选择 : WCF vs. ASP.NET Web Api

Question

我们目前有一个 .NET 4 应用程序，它由在后台运行的 Windows 服务和本地或远程客户端(通常只有 1-3 个)组成。

客户端有一个 WPF GUI，需要一些来自 Windows 服务的数据。因此，我们将 WCF 与 NamedPipe 绑定(bind)用于本地客户端，将 NetTcp 绑定(bind)用于远程客户端。这可行，但我们经常遇到无法访问的端点( channel 故障或未找到等)的问题。我们已经尝试重建故障连接，但它似乎非常脆弱......

现在进入 Web Api:看起来基于 HTTP 的堆栈可能更健壮(没有 channel ，没有端点，也可以在 Windows 服务中自托管)。 channel 中断似乎没有问题，因为每个请求都是单独处理的。因此，如果某些事情失败了，您只需重复请求即可。 (而且我们有其他应用程序使用 ASP.NET MVC 的经验，所以这对我们来说并不新鲜)。

现在我们正在考虑什么可能是我们最好的选择。是“强化”我们现有的 WCF 服务(一个服务接口(interface)，大约 15 个操作)还是将接口(interface)移动到 Web Api 并作为 HTTP 请求(使用 JSON 数据)运行它更好？性能不是我们这里的主要问题......

有任何想法吗？
哈特穆特

Answer 1

我建议您坚持为您的 WPF 应用程序使用 WCF (SOAP) 服务，而不是迁移到 Web API。有许多的原因。首先，我认为我们需要考虑新的 Web API 试图解决的问题——即提供一个支持 RESTful/HTTP/超媒体服务的框架。这可能非常适合构建大量使用 HTTP 的应用程序，例如 Web、移动和 JavaScript 应用程序，在这些应用程序中，您希望最大化服务的“覆盖范围”或互操作性(无论平台如何)。这并不是说您不能将它用于 WPF 客户端，但在您的情况下，所有流量都在您的域中，因此坚持当前的实现更有意义。

您为您的服务/客户所做的绑定(bind)选择对我来说听起来不错。我将专注于您的 channel 出现故障的原因并解决这些问题。您可能还想考虑通过 IIS 托管您的服务并使用 WAS 来公开您的非 HTTP 端点。过去我在这方面取得了很大的成功，而且大部分情况下都相当稳定。它还消除了管理您自己的主机的一些麻烦。如果您担心 TCP 绑定(bind)错误，那么只需创建一个新的 HTTP 或 wsHTTP 端点并使用它。这将为您提供与 web api 使用的完全相同的传输，而无需更改您的编程模型。