DotNetify: Multicast View Model for Building Collaborative Web Apps with SignalR

version 3.1 is out, and with it a new capability to write multicast view model classes on cross-platform ASP.NET server. DotNetify What is a multicast view model? Assuming you’re already familiar with , it’s a server-side view model where you can share the same instance with multiple client connections. Any data update to the view model, either by the server or any of the client, will be simultaneously sent to all. dotNetify and its server-side MVVM approach to web app development SignalR Why multicast view model? There are many applications for this, practically everything that requires real-time communication to or among multiple clients, i.e. a simple IoT broadcast, chat apps, multiplayer games, and all kinds of online collaborative tools. But surely this can all be done with just a SignalR hub class like every chat tutorial love to show? The answer is yes, but… let’s take a look at any of those chat app examples. It is deceivingly simple, for if you continue to go down that path and start to build more advanced features, you would likely end up with complex, tightly-coupled code — both on client and server — that aren’t easy to write tests for! MVVM design pattern helps keep your code highly testable by separating the business logic from infrastructural concerns. DotNetify abstracts out the nitty-gritty of SignalR that for the most part you wouldn’t even know it’s there, so you could concentrate on building the features your customer wants. How it works This is how you define a multicast view model: public class MyChatApp : {} MulticastVM It’s a plain C# class that inherits from a dotNetify’s base class. For the client-side script — we’ll use React for this, we’ll add a component to connect to this view model: Whenever this component is rendered on multiple browsers, the server will always give it the same view model instance. Let’s add the textboxes for some basic chatting: And here’s the complete server-side view model that will produce the same result as the official SignalR chat example: public class MyChatApp : {public List Messages { get; } = new List ();public Action Message => this. ("Messages", msg);} MulticastVM AddList Notice that we’ve completely removed direct SignalR method invocations from the code, and use property / command bindings to get the data flowing seamlessly between the server and all the client browsers that are connecting to this view model. When you do need to get more information on the connecting clients, you could inject and to the view model. These interfaces provide ambient context on the currently connecting client, such as the SignalR connection ID, claims-based identity, IP address used, and so on. IPrincipalContextAccessor IConnectionContext Partitioning instances Beyond just a single instance, some use cases will want to have a different instance for a different group of connections. For example, an authenticated user can simultaneously connect from a desktop and a smartphone and share one view model instance that’s not shareable with other users. SignalR has the capability to define and broadcast to groups, which is scalable to multiple servers when Redis is configured. With , defining a group is as simple as overriding the property: MulticastVM GroupName public class PerUserVM : {private readonly _principalAccessor; MulticastVM IPrincipalAccessor public override string GroupName{get => _principalAccessor.Principal.Identity.Name;} public PerUserVM( principalAccessor){_principalAccessor = principalAccessor;}} IPrincipalAccessor The value will be dynamic, based on the context of the calling connection. The way this works is, when an authenticated client with the identity name connects, a new instance will be created and associated with the client’s group name ‘UserA’. When again connects from a different device, thus a different connection, it will be given any existing instance with matching group name. And since the identity name is the same, both devices will use the same view model instance. But when connects, there will be no matching group name, and another instance will be created and associated with ‘UserB’ group name. GroupName UserA UserA UserB Using this mechanism, you could extend this to check the group membership of a connecting user from a data store, and create partitioned view model instances for any particular group. Direct message What if we need to send a message to only certain users? With you would be able to associate the connected users with their SignalR connection IDs, and once you have these, use base method to send messages to one or more connections of your choosing: IConnectionContext Send (new List { connId, ... }, stateName, stateValue); Send How to get started If you’re new to dotNetify, you probably have a lot of questions on the example code above. Do visit website, where the APIs are explained in details. There is plenty of other materials there: live demo, templates, and even UI toolkit for React. Everything is free and open source. dotnetify.net Thank‘s’ for reading!