反正有没有看到ClientProxy的可用客户端功能?

时间:2015-04-15 23:42:03

标签: signalr

我正在调试一个大型应用程序,它在客户端端点上有一些与服务器端调用相关的错误,而不会导致客户端调用。从调试的角度来看,我在海上有点迷失。它可以帮助我查看可用的客户端功能列表,但可能无法使用。从tracelog的角度来看,我看不到任何关于函数调用有任何问题的条目(system.diagnostics下面的条目)。

有关单元测试或调试策略的任何想法吗?

<switches>
  <add name="SignalRSwitch" value="Verbose" />
</switches>
<!-- Specifies the trace writer for output -->
<sharedListeners>
  <!-- Listener for transport events -->
  <add name="SignalR-Transports" type="System.Diagnostics.TextWriterTraceListener" initializeData="transports.log.txt" />
  <!-- Listener for scaleout provider events -->
  <add name="SignalR-Bus" type="System.Diagnostics.TextWriterTraceListener" initializeData="bus.log.txt" />
  <!-- Listener for hub discovery events -->
  <add name="SignalR-Init" type="System.Diagnostics.TextWriterTraceListener" initializeData="init.log.txt" />
</sharedListeners>
<trace autoflush="true" />

2 个答案:

答案 0 :(得分:2)

AFAIK,至少在服务器上,没有。在客户端上定义的用于处理服务器到客户端调用的代码只是服务器完全不知道的一堆事件处理程序。从理论上讲,您可以使用不同的处理程序,使用多个客户端代码,服务器无需了解所有代码。这将是完全合法的,并且更容易理解为什么不可能知道你的要求。

在幕后,SignalR只为每个服务器到客户端呼叫发送消息,其中每条消息都有一些字段,其中一个包含客户端要触发的事件的名称。因此,服务器只发送字符串并忘记它们,客户​​端接收它们并动态检查是否存在该名称的任何处理程序。

如果客户端上不存在Clients.All.foo("bar"),您的目标是避免调用foo之类的内容吗?也许你的代码中有几个地方可能会发生这种情况,因此当重组/重构内容时,很难控制动态调用?如果是,则一个建议可以是定义新的C#类型,并将该类型的相应方法内的每个动态调用集中在服务器上。通过使用该类型的实例(它也可以是静态的),您的集线器或通过IHubContext的呼叫可能不会出错,并且您可以将动态呼叫集中在一个地方。这当然不能完全解决问题,但有助于控制它,因为动态调用只在一个地方,并且更容易使它们与客户端代码保持一致。

答案 1 :(得分:0)

有些库包装SignalR并使其更加静态类型化。我是一个名为SignalR.EventAggregatorProxy

的库的作者

它是一个pub / sub包装器,消息是使用动态脚本代理到客户端的C#类(很像集线器代理)