5

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

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

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

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

有任何想法吗？哈特穆特

4

1 回答 1

4

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

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

于 2012-04-19T01:14:56.507 回答