Back when this book was written, using the web for building enterprise applications was a new practise.
Although, in the beginning, it was a common practise to mix presentation logic with business logic and even persistence logic (think HTML mixed with SQL), it soon became clear that it was very difficult to change the UI if it was not decoupled from all other logic.
The MVC patter, which was around since the late 1970s, came to the resqueue and became the common practise. The most important reason to use MVC is to decouple presentation logic from business logic.
In the MVC pattern we have 3 roles:
- View: Draws the user interface;
- Controller: We can have 2 types of controller:
- Input Controller: Receives the data from a view, filters it, validates it, forwards it to the model, and returns response data back to a view;
- Application Controller: These controllers sit between an input controller and the model. Their responsibility is to control the application flow, the application use case. Unlike the input controllers, who are tied to a specific view, the application controller can be used by different views/input controllers. Now days the application controller is the entry point to one of the application use cases (ie. a CQRS command handler or a domain service).
- Model: The model is the technical implementation of the domain. The model is not an object type, it is a set of objects of many types and with different responsibilities. In a model we can find Entities, Value Objects, Factories, Services, Commands, Handlers, Events and many others. The core idea is: The model is the technical implementation of the Domain.
The book continues talking about view and controller patterns, however it is an outdated discussion as now days the standard implementation is to have views built with a template engine, an input controller tied the view and some kind of application controller (ie. a command handler or a service) which is the entry point to one of the application use cases.
@hgraca 