Book Image

SignalR Blueprints

By : Einar Ingerbrigsten
Book Image

SignalR Blueprints

By: Einar Ingerbrigsten

Overview of this book

Table of Contents (18 chapters)
SignalR Blueprints
Credits
About the Author
Acknowledgments
About the Reviewers
www.PacktPub.com
Preface
9
Debugging or Troubleshooting
Index

Patterns


Techniques that repeat can be classified as patterns; you probably already have a bunch of patterns in your own code that you might classify even as your own patterns. Some of these become popular outside the realms of one developer's head and are promoted beyond just this one guy. A pattern is a well-understood solution to a particular problem. They are identified rather than "created". That is, they emerge and are abstracted from solutions to real-world problems rather than being imposed on a problem from the outside. It's also a common vocabulary that allows developers to communicate more efficiently. A popular book that aims to gather some of these patterns is Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley Professional. You can find a copy at http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612.

We will be using different patterns throughout this book, so it's important to understand what they are, the motivation behind them, and how they are applied successfully. The following sections will give you a short summary of the patterns being referred to and used.

Model-View-Controller

Interestingly enough, most of the patterns we have started applying have been around for quite a while. The Model-View-Controller (MVC) pattern is a great example of this.

Note

MVC was first introduced by a fellow Norwegian national called Dr. Trygve Reenskaug in 1973 in a paper called Administrative Control in the Shipyard (http://martinfowler.com/eaaDev/uiArchs.html). Since then, it has been applied successfully in a variety of frameworks and platforms. With the introduction of Ruby on Rails in 2005, I would argue the focus on MVC really started to get traction in the modern web development sphere. When Microsoft published ASP.NET MVC at the end of 2007, they helped gain focus in the .NET community as well.

The purpose of MVC is to decouple the elements in the frontend and create a better isolated focus on these different concerns. Basically, what one has is a controller that governs the actions that are allowed to be performed for a particular feature of your application. The actions can return a result in the form of either data or concrete new views to navigate to. The controller is responsible for holding and providing any state to the views through the actions it exposes. By state, we often think of the model and often the data comes from a database, either directly exposed or adapted into a view-specific model that suits the view better than the raw data from the database. The relationship between model, controller, view, and the user is summarized in the following diagram:

A representation of how the artifacts make up MVC (don't forget there is a user that will interact with all of these artifacts)

With this approach, you separate out the presentation aspect of the business logic into the controller. The controller then has a relationship with other subsystems that knows the other aspects of the business logic in a better manner, letting the controller only focus on the logic that is specific to the presentation and not on any concrete business logic but more on the presentation aspect of any business logic. This decouples it from the underlying subsystem and thus more specialized. The view now has to concern itself with only view-related things, which are typically HTML and CSS for web applications. The model, either a concrete model from the database or adapted for the view, is fetched from whatever data source you have.

Model-View-ViewModel

Extending on the promise of decoupling in the frontend, we get something called Model-View-ViewModel (MVVM); for more information, visit http://www.codeproject.com/Articles/100175/Model-View-ViewModel-MVVM-Explained.This is a design pattern for the frontend based largely on MVC but it takes it a bit further in terms of decoupling. From this, Microsoft created a specialization called MVVM, as it is called today.

Note

MVVM was presented by Martin Fowler in 2004 to what he referred to as the Presentation Model (which you can access at http://martinfowler.com/eaaDev/PresentationModel.html).

The ViewModel is a key player in this that holds the state and behavior needed for your feature to be able to do its job without it knowing about the view. The view will then be observing the ViewModel for any changes it might get and utilize any behaviors it exposes. In the ViewModel, we keep the state, and as with MVC, the state is in the form of a model that could be a direct model coming from your data source or an adapted model that is more fine-tuned to the purpose of the frontend.

The additional decoupling, which this model represents, lies within the fact that the ViewModel has no clue to any view, and in fact should be blissfully unaware that it is being used in a view. This makes the code even more focused and it opens an opportunity of being able to swap out the view at any given time or even reuse the same ViewModel with its logic and state for the second view.

The relationship between the Model, View, ViewModel, and the user is summarized in the following diagram:

The artifacts that make up MVVM (don't forget the user interacts with these artifacts through the view)

Command Query Responsibility Segregation

Back in 1988, Betrand Meyer published a book, Object-oriented Software Construction (https://archive.eiffel.com/doc/oosc/page.html). In this book, one of the things being addressed was the separation of actions being performed in the system and data being returned. The data displayed and the actions performed are, in fact, two completely different concerns and it's described as commands for the tasks being performed and queries for the data one gets. At its core, there are no methods or functions that can perform an action and return data. These are separated out as two different operations, leading to the concept of Command Query Separation (CQS); more information can be found at http://codebetter.com/gregyoung/2009/08/13/command-query-separation/. Greg Young and Udi Dahan reached the conclusion of refining CQS into something called Command Query Responsibility Segregation (CQRS). At the heart of this sits the SOLID principles, especially with SRP, whereas the ideas of separation of concerns is on top (more information is available at http://deviq.com/separation-of-concerns). The evolution in CQRS over CQS was to take what was identified by Bertrand Meyer on the functional level and apply it to the object and architectural levels.

The basics of this is to really treat read and the write as two different pathways and to never mix them. This means that you never reuse any code between the two sides. Getting data through queries should never have side effects on the data as it can't write anything. Commands do not return any data as they only get to perform the action it is set out to do. A command is a data holder that holds the data that is only specific to this command. It should never be looked on as a vessel for large object graphs that gets sent from the client.

Going beyond the separation of read and write, CQRS is really about creating the models needed for the different aspects of your solution (never reuse a model between them). This would mean that you will end up having read models, write models, reporting models, search models, view models, and so on. Each of these is highly specialized for their purpose, leading again to decoupling your system even further. CQRS can be deployed with or without events that connect the segregated parts at its core; this all depends on whether or not your organization can be event driven or not. We will discuss CQRS in more depth later in this book.

CQRS is often seen as complementary to Domain Driven Design (DDD)—a practice that focuses on establishing the model that represents the domain you're making the software for (for more information, visit http://dddcommunity.org/learning-ddd/what_is_ddd/). It holds terminology for how you do this modeling and defines well-defined patterns for the different artifacts that make up your domain model. At the core of this sits the idea of a ubiquitous language that represents your domain; a language that is not only understood by a developer, but also by the domain experts and ultimately the users of the system. Some key facts that you need to bear in mind are as follows:

  • Avoid unwanted confusion and also avoid having the need for translations between the different stakeholders of a software project.

  • Capture the real use cases and how you should focus on capturing them while not focusing on technical things. Often, we find ourselves not really modeling the business processes accurately, leading to monster domain models that potentially could bring the entire database into memory. Instead of this, focus on the commands or tasks, if you will, which the user is performing. From this, you will reach different conclusions for things (such as transactional boundaries).

  • Bounded contexts, another huge aspect of DDD, is the idea that you necessarily don't have one big application but rather many small ones that don't know about each other and live in isolation only to be composed together in the bounded context of the composition itself. Again, this leads to yet another level of decoupling.

The following diagram shows the division found in a full CQRS system with event sourcing and the event store and how they are connected together through events being published from the execution side.