多年来,由于各种原因,我们所在的公司已经大量投资使用Windows Communication Foundation(WCF)。目前,我们正在将主要开发平台从Visual Studio 2015升级到Visual Studio 2022。遗憾的是,我们发现我们的WCF客户端和服务器应用程序需要比我们预期的更多的工作才能将它们升级到Visual Studio 2022和更新的.NET框架;它们当然不像以前那样流畅。我们计划保留使用WCF的现有应用程序,但正在考虑其他新应用程序的选项。似乎被推广的主要选项是gRPC,然而,根据我目前了解到的情况,对于我们想要做的某些事情,它似乎是一个非常糟糕的替代品。对于我们,WCF中一些关键的价值在于:
- 单向函数调用(即只要我们知道调用已传递,我们就不需要等待直到其完成)。我了解到这可以通过gRPC实现。
- 完全双向通信(即客户端可以对服务器进行调用,反之亦然;服务器可以对客户端进行调用)。我了解到使用“流”可以近似实现此功能,但不容易。
为了说明,考虑涉及三种应用程序类型的简化情况:
- 声音请求者。一个应用程序,请求在不同位置播放不同的声音,并更改声音参数。
- 声音播放器。可以播放请求的声音并更改其参数的应用程序。它可以通知声音已完成。
- 声音处理代理。位于声音请求者和声音播放器之间的应用程序。
我们的WCF实现将声音处理代理作为WCF服务器,声音请求者和声音播放器应用程序作为连接到服务器的客户端。这非常适合我们;代理不需要知道要连接哪些播放器和请求者,它们连接到它(并且可以随时这样做)。代理只提供“编排”服务。下面是一个简化的序列图,以说明可能进行的调用类型:
我的问题是:“如果使用gRpc实现,我们如何在SoundPlayer上实现调用(例如CreateSound,PlaySound等)?”如果我理解正确,由于SoundPlayer是客户端(而不是服务器),我们需要将这些实现为从播放器到服务器的调用的“返回”流。有更简单的方法吗? (我知道我们可以将SoundPlayer作为服务器,让SoundHandlerProxy作为客户端连接-但这意味着代理需要知道它要连接的所有播放器,我们宁愿避免这种情况。) 或者,除了gRpc之外,我们还可以迁移到其他东西(最好是未来至少十年稳定的东西)吗?