Previously I talked about how to set up the server side of SignalR for facilitating real-time communication. One of the parts that I don’t particularly care for in that default implementation is that the hub methods (the messages that are sent to connected clients) are identified by strings. Sure, you could create some string constants to identify them, but that still leaves you without IntelliSense / knowing what parameters are expected when sending those messages.
Strongly-Typed Hubs
Luckily, SignalR lets you define an interface that describes those message signatures, and then you can use it to have full IntelliSense to know what parameters are expected. This is especially useful when you’re injecting an IHubContext in to a different service.
Using this method makes things a lot cleaner. You don’t have to use magic strings or make a constants file, and you don’t have to hold the parameter list in your brain while you’re working.
Kevin
the strongly typed hub is a bit confusing. noticed that MyHub did not implement the History mehtod, but when invoking the History method defined in IMyHub, does signalR magically translate that into the old way of invoking the method?
Robert
Hey Kevin, interface defines server -> client communication messages, whereas methods on the hub itself are for client -> server communications.
Yep, SignalR is going to use those methods (and their names) to build up the message to send across the network. The IHub
Kevin
thx Robert. that explains the key of strongly typed hub