The complete title should be a fair confrontation between a pure MVC only approach and the benefits we can gain by pairing it up with CQRS. As this might have hinted already, they can live together, and in most implementations around the actually do.
If we compare the pure approach on both there are some major differences, as it’s natural to expect. Let’s take a step back first and get our head around what are the most common design patterns currently.
MVC
Model, View and Controller. Each of them with their separate responsibility. The user will see a View and trigger an action that will be handled by the Controller thus updating a Model (which is our data representation). Once the Model has been updated any subsequent load of the View will reflect those changes.
MVC alternatives
There are two mainstream alternatives to MVC that can be adopted to achieve similar results. Most of the times the real difference is based on the preferred technology support or framework available that already favors one over the other, rather than a real architectural choice. These alternatives are MVVM and MVP (not the Minimum Viable Product). Each has 3 main components.
MVVM is a composition of Model, View and ViewModel (following the ancient naming tradition of “let’s just keep reusing the same nouns to make it more confusing”). Both Model and View are the same, the ViewModel serves a slightly different purpose from the Controller in MVC. More in detail, while MVC’s Controller acts as a man in the middle to coordinate the other components, MVVM’s ViewModel is connected with a 2-way data-binding to one or more views; this component represents the state of data in the Model.
MVP, where the P is the Presenter, which can be a lose form of the Controller. Sometimes also a supervising controller is present to handle the events coming from the view.
In case CQRS is forgotten
If CQRS as a term is unfamiliar at all, I suggest the very complete Udi Dahan’s explanation, otherwise is an architectural approach, not a patterns per se. Alternatively CQRS can be looked at the architectural equivalent of the CQS principle for imperative programming.
Similarities between MVC and CQRS
CQRS can be seen as a precise extension of the MVC pattern, as it advocates for having a very similar split of responsibility. Let’s assume we have 2 different MVC models: MVC-Read and MVC-Write. There is no distinction from the views of either, models would be different from each other and the controllers are split over the responsibility of reading and writing. In a pure RESTful implementation the read-controller shall contain only GET methods, while the write-controller shall contain everything but GET methods ( i.e. POST, PUT, DELETE). The only component missing is one that reads from the write-model, aggregates information if needed, and pushes it to the read-model for availability. This would be a good sample to describe the inner workings of a CQRS approach, after all Greg Young said it first.
An additional hint in favor of this same argument is the fact that it’s easy to find numerous ASP.NET MVC implementation of CQRS.
Differences between MVC and CQRS
The caveat here is assuming that we are referring to common implementation of pure MVC and CQRS implementation. The main difference I would point out is the execution time of the 2, MVC would generally act as a synchronous application while CQRS would act asynchronously. Moreover we are entering the painful realm of Eventual Consistency. Why painful you may ask ? Because if you study the CAP theorem you also realize that Consistency is a lot more un-eventual that one might expect it to be.
Regardless of the implementation, another difference is related to the amount of components. CQRS will have more components than MVC.
CQRS allows for higher theoretical scalability. This is not a feature by itself, it can achieve it by increasing software complexity and making debug more difficult, therefore it is not a valid reason to favor it over other options if scaling is not an issue with other implementations.
CQRS allows for better view-model composition, as each element can be tailored to suit the needs of their respective consumer.
Conclusions
MVC and CQRS can work together, or you can pick one over the other depending on your requirements. CQRS will add complexity to the solution by adding more components and changes of expected behavior (see Eventual Consistency). Don’t pick CQRS over MVC for a simple application, it’s probably not worth the effort.