The Model View Controller paradigm very nicely separates the web server layer into the different regions of responsibility. Unlike in ASP.NET Web Forms, the object model, controller logic and presentation logic¹⁾ don't get hopelessly mixed up.

Still, there is too much business logic in classic controllers for my taste. The web server should be there merely for presenting an already existing model, and for passing through commands to change that model to an existing application layer.

Thus, I am using ASP.NET MVC in combination with ASP.NET Web API. When a GET request is made on my MVC application, the request is delegated to a Model inside the Web API, which delivers the data back to the MVC controller, which can then present it in a view. Since both ASP.NET MVC and Web API share the same process²⁾, the Web API can use the same context for authorization as MVC.

Separating it this way, an AJAX call to GET the same data can be made to the same ASP.NET Web API controller, which then presents the same data. The Query side thus only needs to be implemented once and can be used from just about anywhere³⁾.

But even the ASP.NET Web API will delegate the query to a query service in the application layer, i.e. the Web API is just a (exchangeable) remote facade for the query layer.

The Command Side is not implemented in ASP.NET MVC at all when applying CQRS. In classical ASP.NET MVC, changes are POSTed back as changes to the model in a RESTful way. For me, that is very CRUD-like, and the behavior of the system is not captured, i.e. why the model has been changed.

Thus, unless it is a very simple application, where there is only one reason for a model to change, I will have a strict separation of queries and commands. Commands will be POSTed to the ASP.NET Web API service layer - in a RESTful way, mind you. The Web API then delegates the handling⁴⁾ of these commands to the application layer⁵⁾, either by placing them onto a command bus, or directly in process⁶⁾.