Page 58 - MSDN Magazine, April 2018

Cutting EdgE DINO ESPOSITO Discovering ASP.NET Core SignalR
ASP.NET SignalR was introduced a few years ago as a tool for ASP.NET developers to add real-time functionality to applications. Any scenarios in which an ASP.NET-based application had to receive frequent and asynchronous updates from the server—from monitoring systems to gaming—were good use cases for the library. Overtheyears,IuseditalsotorefreshtheUIinCQRSarchitecture scenarios and to implement a Facebook-like notification system in socialware applications. From a more technical perspective, SignalR is an abstraction layer built over some of the transport mechanisms that can establish a real-time connection between a fully compatible client and server. The client is often a Web browser and the server is often a Web server, but both are not limited to that.
ASP.NET SignalR is part of ASP.NET Core 2.1. The overall programming model of the library is similar to that for classic ASP.NET, but the library itself has in fact been completely rewritten. Still, developers should quickly become comfortable with the new scheme, once they adjust to the changes that exist here and there. In this article, I’ll discuss how to use the new library in a canonical Web application to monitor a remote, and possibly lengthy, task.
Setup of the Environment
You may need a couple of NuGet packages to use the library: Microsoft.AspNetCore.SignalR and Microsoft.AspNetCore.Sig- nalR.Client. The former provides the core functionality; the latter
Figure1TheStartupClassofaSignalRASP.NETCoreApplication
package is the .NET client and is needed only if you’re building a .NET Client application. In this case, we’re using it through a Web client, so a SignalR NPM package would be needed instead. I’ll dis- cuss the details of this later in the article. Note that using SignalR in the context of a Web application based on the MVC application modelisnotarequirement.YoucanusetheservicesoftheSignalR library directly from an ASP.NET Core console application and can also host the server part of SignalR in a console application.
Not surprisingly, the startup class of the application needs to contain some specific code. In particular, you’ll add the SignalR service to the collection of system services and configure it for actual use. Figure 1 presents the typical status of a startup class that uses SignalR.
The configuration of the SignalR service consists in the definition of one or more server routes that bind to one or more endpoints within the server-side environment. The MapHub<T> method links the specified names, which will be part of a requesting URL, to an instance of a hub class. The hub class is the beating heart of the implementation of the SignalR protocol and is where the client calls are handled. You create a hub for each logically related group of calls the server-side intends to accept and handle. A SignalR con- versation is made of messages being exchanged between two parties and each party may call methods on the other party receiving no response, one or multiple responses, or just the notification of an error. Any ASP.NET Core SignalR server implementation will expose one or more hubs. In Figure 1, you have two hub classes— UpdaterHub and ProgressHub—bound to unique strings that will be internally used to compose the URL target of the actual calls.
The Hub Class
The hub class in a SignalR application is a plain, simple class that inherits from the base hub class. The base class has the sole purpose of saving developers from writing over and over again the same boilerplate code. The base class only provides some infrastructure but no predefined behavior. In particular, it defines the members in Figure 2.
The simplest hub class is as minimal as the following:
public class ProgressHub : Hub {
}
Interestingly enough, that’s just the form of the hub if you use it from within a controller method in the context of an ASP.NET Core MVC application. Almost all of the examples you may find about ASP.NET Core SignalR (including the chat example) tend
public class Startup {
public void ConfigureServices(IServiceCollection services) {
services.AddMvc();
services.AddSignalR(); }
public void Configure(IApplicationBuilder app) {
app.UseStaticFiles(); app.UseDeveloperExceptionPage();
// SignalR app.UseSignalR(routes => {
routes.MapHub<UpdaterHub>("/updaterDemo");
routes.MapHub<ProgressHub>("/progressDemo"); });
app.UseMvcWithDefaultRoute(); }
}
52 msdn magazine