Model View Controller (MVC) is a model for dividing software into three components Data Model, View/Presentation and Program Controller. The pattern can be used both as an architectural pattern and as a design pattern. The aim of the model is a flexible program design that facilitates subsequent modification or expansion and enables the reusability of the individual components. It is then possible, for example, to write an application that uses the same model and then makes it accessible to Windows, Mac, Linux or the Internet. The implementations use the same model, only controller and view have to be implemented anew. The MVC concept was first described in 1979 for user interfaces. However, it is now regarded as a de facto standard for the rough design of many complex software systems, sometimes with differentiations and often several modules divided according to the MVC pattern.
Classic architectural pattern
Model
The model contains data that is represented by the presentation. It is independent of presentation and control. The changes to the data are announced to the presentation by the “Observer” design pattern. In some implementations of the MVC pattern, the model contains business logic that is responsible for modifying the data.
---
Presentation
The presentation is responsible for presenting the data of the model and realizing the user interactions. It knows the model whose data it presents but is not responsible for processing that data. Furthermore, it is independent of the controller. The announcement of user interactions to the controller is done according to the design pattern “Observer”. The presentation is notified of changes to the data in the model using the Observer design pattern and can then update the appearance. The presentation often uses the Composite design pattern.
Controller
The controller manages the presentation and the model. The presentation informs it about user interactions (using the Observer design pattern), evaluates them, and then makes adjustments to the presentation and changes to the data in the model. In some modern implementations of the MVC pattern, the controller no longer updates the data in the model directly, instead indirectly updates the data by accessing the business logic implemented in the model. In a special case of the MVC pattern, the controller can also manage multiple presentations or multiple models at the same time.
Undetected functionalities
Because the MVC pattern must be implemented differently in different programming languages, there is no one-size-fits-all definition of where the business logic should be located within the MVC classes. For historical reasons, it is often still programmed in the controller but is increasingly implemented in the model today. Thus, the model contains all business objects with all their data and functions and can therefore be tested in isolation, quickly, completely and automatically. Some MVC frameworks strictly dictate were to implement the business logic, others leave this decision to the software developers.
Similarly, the location for validating user input is not defined. Simple format validations can already be implemented in view. Validations, which need to take greater account of the business logic, are more likely to be implemented in the model or the control.
Also, the formatting of the raw data and the internationalization is not defined where they take place. For reasons of development efficiency, it is often a good idea to integrate them into the model, so that you can limit yourself to the creation of widgets or templates when viewing. On the other hand, aspects of the representation are shifted into the model, which is quite contrary to the basic idea. As a variant, it is therefore also advisable to provide independent functional areas for this purpose, which do not have to be assigned to models, views or controllers.
Current implementations
The terms of the original MVC pattern are often borrowed today to make systems comprehensible that are far more complex than the software of the time. It depends on the perspective of the subsystem under consideration which elements are designated by it. For example, a web browser could be understood as a view of a larger overall system, while a single form element in the browser, in turn, consists of a small data model, the associated representation and its control. The basic idea of separating model, view and controller has been preserved but is used more finely granulated and nested.
In a broader sense, the MVC pattern in web applications is distributed across servers and browsers, making it more complex than the classic MVC pattern. In the abstract, the browser takes over the visible representation and direct user input, as well as the non-page-specific functions of the controller and view. The server takes care of specific control of the browser by communicating with it via HTTP.
In the narrower sense, however, this only means the server-side program. Once again, you can distinguish between the webserver for static websites or its delegation to special additional programs. The term MVC is used in particular in the context of such additional programs to the webserver.
