tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== ASP.NET MVC - Model View Controller======
The Model View Controller paradigm very nicely separates the web server layer into the different regions of responsibility. Unlike in [[csharp:aspnet:webforms|ASP.NET Web Forms]], the object model, controller logic and presentation logic((which can be quite complex as well)) 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 [[csharp:aspnet:webapi|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((in my architecture)), 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((If there is an application query layer, the MVC and Web API controllers can both delegate to that layer, i.e. the MVC controller could bypass the Web API controller. The decision may be a matter of taste, but to keep things simple, the Web API could //be// the application query layer, then all calls would go through it)).
>
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 [[technology:cqrs|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((execution)) of these commands to the application layer((unless, of course, the Web API //is// the application layer)), either by placing them onto a command bus, or directly in process((my preferred way, since my applications are //small enough// to be responsive)).
tawiki

User Tools

Site Tools

Page Tools
