我有[网络方法]。它的作用是在目录中查找* .dat文件，其中目录路径由客户端调用[web方法]提供。
目前客户端调用[web方法]并且代码进入循环检查任何文件。如果发现任何它将返回列表。它也可以显然超时，当它执行时我的客户端代码捕获错误并重新调用[web方法]。
另一种做法是在客户端上打开一个TCP套接字，它会向服务器上的接收套接字服务发送“我在这里”。服务器将查找* .dats的存在，其中包含客户端提供给它的条件。如果它找到1+文件，它将发回'1'。如果没有文件，它将发回'0'。如果客户端从服务器收到“1”，那么我的客户端应用程序将调用[web方法]来检索可用的列表。
我知道我可以使用WCF进行回调，但我想明确地看一下这两个选项。
我也知道SignalR，但我发现如果我使用的是Windows 8之前的操作系统，那么SignalR将恢复为长轮询而不是网络套接字。
我可以理解，使用第一种方法会将“强调”放在服务器上并以第二种方式进行，将均匀分布“压力”，但会涉及重复的TCP调用。
我已经完成了测试，两者似乎都拥有自己的测试。
任何人的意见都会得到感谢。
我的目标，是速度，低内存消耗，易于管理代码，服务器和客户端之间的松散耦合 - 基本上是显而易见的......
感谢...
答案 0 :(得分：1)
如果您正在寻找松散耦合，那么Message Queue的一些实现可能会有所帮助。 虽然这意味着您需要更改部分架构。
我建议将其改为“推送”方式，而不是轮询。
我的方法是这样的：
或者，您可以实现一个消息调度程序服务，该服务负责客户端的消息订阅。这会将订阅管理与您的文件服务分开，这对我来说会更清晰。
实施细节可能因您选择的技术而异。
在工作中，我们有类似的场景，我们使用的WCF服务支持开箱即用的Microsoft Message Queue（MSMQ），并且易于使用NServiceBus框架。 NServiceBus使建立这些发布者/接收者场景变得容易设置。
当然还有很多其他的Message Queue框架可供使用，这正是我亲身体验过的好地方。