asp.net-mvc – 强大的自托管服务器的最佳选择：WCF与ASP.NET We

发布时间：2020-12-16 03:27:15 所属栏目：asp.Net 来源：网络整理

导读：我们目前有一个.NET 4应用程序,它由在后台运行的 Windows服务和本地或远程客户端组成(通常只有1-3个). 客户端有一个WPF GUI,需要来自Windows服务的一些数据.因此,我们将WCF与NamedPipe绑定用于本地客户端,并将NetTcp绑定用于远程客户端.这有效,但我们经常遇

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

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

现在进入Web Api：看起来基于HTTP的堆栈可能更强大(没有通道,没有端点,也可以在Windows服务中自托管).通道损坏似乎没有问题,因为每个请求都是单独处理的.因此,如果某些内容失败,您只需重复该请求. (我们有其他应用程序的ASP.NET MVC经验,所以这对我们来说并不陌生).

现在我们在想什么可能是我们最好的选择.是否更好地“强化”我们现有的WCF服务(一个具有大约15个操作的服务接口)或将接口移动到Web Api并将其作为HTTP请求(使用JSON数据)运行？表演不是我们的主要问题……

有任何想法吗？
哈特穆特

解决方法

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

您为服务/客户端所做的绑定选择听起来不错.我会集中讨论为什么您的渠道出现故障并解决这些问题.您可能还需要考虑通过IIS托管服务,并使用WAS公开非HTTP端点.过去我在这方面取得了很大的成功,而且大部分都非常稳定.通过管理自己的主机,它也消除了一些令人头疼的问题.如果您担心TCP绑定错误,那么只需创建一个新的HTTP或wsHTTP端点并使用它.这将为您提供与web api完全相同的传输,而无需更改您的编程模型.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!