That’s fine. But…what is it, exactly? This, my friends, is the culmination of several hours of trial and error, of attempting different technologies in a bid to create what you see before you: An automated message posted to a chat window.

This is what I was going on about in the previous post about Golden Layout and SignalR. Although what you see here looks like a typical chat layout, behind the scenes it’s a bit chaotic, and I have to go through and clean things up a bit.

From Many to One

The first decision I made was to cut my per-task SignalR hub model down to just one hub. In SR, a hub is a clearinghouse for inbound and outbound traffic. A javascript method can call a function defined in this C# hub, and the C# hub can call methods defined in a javascript script. Because SR uses true network transport through web sockets, this is almost more like a real network application and less like a traditional web application.

The single hub means that all cross-hub communication that I would have had to have done is no longer necessary because everything is in one file. The problem with this is that with just one hub, the entire application is going to be calling in, and that’s going to result in a lot of shippers and handlers defined in this one file.

Basement Level Processing

To combat potential bloat, I’m going to re-silo on the back end of the SR hub. Whereas before I was going to have one hub per silo, I will now have one business logic silo per major activity. For example, if chat needs to have any kind of business logic applied (say, if we need to determine if you are a special-case account and need a different color to your text), the data will first be passed to main hub, then to the chat logic silo, handled, and returned to the main hub to be sent back to the client. Chat’s kind of a bad example since it’s not complex, but there will be other processes which will need some heavy lifting.

It’s All About The Data, Marty

Way down deep, then, we’ll have the data access layer. This will only be accessible through these individual business logic silos.

I am using Entity Framework for right now because it’s easy to set up without having to touch the database, but I know it has some pretty severe quirks that can frustrate those who don’t work with it regularly (read: me). Rather than create databases everywhere, I set up a SQL Server(less) instance on Azure. I have character and room tables defined with the bare-bones fields that I need and have seeded them with some initial testing data.

What’s All This Mumbo Jumbo, Then?

The screenshot is really the result of bringing this all together.

1. When the app fires up, the javascript creates the Golden Layout display and instantiates a proxy for SignalR so the javascript can talk to the “server”.
2. OnConnect (ideally, but there are issues here), the app is pulling the “Scopique” character from the database. Later, this will actually happen well before we load the GL display, so we’ll have the character data on file, or will have enough identifiers to be able to pull it up from the data-basement.
3. When we return to the javascript from our connection event, we call a server method enterRoom(“lobby”). This takes our current character “Scopique” and adds him to a SignalR Client group called “lobby”. Groups allow us to broadcast messages to just those clients who are in the same group — basically, a chat room. enterRoom() also updates the “Scopique” record with his new room ID.
4. As part of the AddClientToRoom() server method, we call a javascript method addClientToRoom(usr) which adds the name “Scopique” to the room inhabitants panel on the right of the chat window.
5. When control returns to enterRoom(), the final action is to call a local method SendRoomChat with a formatted message announcing the arrival of a new character. This method sends that message over to the javascript addRoomChatMessage, which displays it to all people who are in the same room as “Scopique” (i.e. the “lobby”).

And this is all it does. Technically, I can send messages using the text box, and other members (browsers) who are similarly logged into the “lobby” room will see them, but I don’t yet have a way to select which “character” you’re logged in as.