Model View Controller
Model View Controller ( MVC , English for model presentation control ) is a pattern for dividing software into the three components data model (English model ), presentation (English view ) and program control (English controller ). The pattern can be used both as an architectural patternand as a design pattern. The aim of the sample is to create a flexible program design that facilitates subsequent changes or extensions and enables the individual components to be reused. It is then possible, for example, to write an application that uses the same model and then make it accessible for Windows, Mac, Linux or the Internet. The implementations use the same model, only the controller and view have to be implemented anew.
The MVC concept was first described in 1979 for user interfaces in Smalltalk by Trygve Reenskaug (Seeheim model), who was then working on Smalltalk at Xerox PARC . In the meantime, however, it is considered the de facto standard for the rough draft of many complex software systems, sometimes with differentiations and often several modules each divided according to the MVC pattern.
Classic architecture pattern
The three components depend on each other to a different degree depending on the implementation:
Model ( model )
The model contains data that will be 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 template. In some implementations of the MVC pattern, the model contains business logic that is responsible for changing the data.
Presentation ( view )
The presentation is responsible for the representation of the data of the model and the realization of the user interactions. It knows the model whose data it is presenting, but is not responsible for processing this data. It is also independent of the controller. The notification of user interactions to the control is done according to the "observer" design pattern. The presentation is notified of changes to the data in the model using the Observer design pattern and can then update the representation. The presentation often uses the "compound word" design pattern .
Control ( controller )
The control manages the presentation and the model. The presentation informs them of 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 directly updates the data in the model; instead, it updates the data indirectly by accessing the business logic implemented in the model. In a special case of the MVC pattern, the control can also manage several presentations or several models at the same time.
Functionalities not specified
Business logic
Since the MVC pattern has to be implemented differently in different programming languages, there is no generally applicable 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 now increasingly implemented in the model. 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 where to implement the business logic; others leave that decision up to the software developers.
Validation of user input
Similarly, the location for validation of user input is not defined. Simple format validations can already be implemented in the view. Validations, which have to take the business logic more into account, are more likely to be implemented in the model or in the control system.
Data formatting and internationalization
Also for the formatting of the raw data and the internationalization it is not defined where this takes place. For reasons of development efficiency, it is often advisable to integrate these into the model so that you can limit yourself to creating widgets or templates when viewing. On the other hand, aspects of the representation are shifted into the model, which is in contradiction to the basic idea. As a variant, it is therefore also advisable to provide separate functional areas for this, which you then do not have to include in the model, view or controller.
Today's implementations
The terms of the original MVC pattern are now often borrowed in order to make systems understandable that are far more complex than the software of the time. It depends on the perspective of the sub-system under consideration which elements are referred to. A web browser could be understood as a view of a larger overall system, while a single form element in the browser already consists of a small data model, the associated display and its control. The basic idea of separating model, view and controller has been retained, but is used in a more finely granulated and nested manner.
While many projects define themselves as model-view-controller architecture, the term is used in a wide variety of ways. New terms such as the Model-View-Presenter -, the Model-View-ViewModel - or the Model-View-Adapter pattern are establishing themselves , which try to describe the variants more precisely.
Widget libraries for desktop applications
The individual components of graphical interfaces, such as menu items or editor components, are called widgets . Widgets are characterized by the fact that, in addition to the presentation, they also combine typical features of the classic controller in one component, such as event handling. Some widgets, such as B. Selection lists, can even have their own internal model, which must then be synchronized with the actual model.
Although the widgets break through the three-way division, one still speaks of a model-view-controller architecture. There are also components such as filters for sorting or confirmation dialogs that cannot be clearly classified into the classic three-way division.
When using the widget libraries, the controller leaves part of the classic controller function to the widgets and is limited to controlling the model and possibly other components of the view.
The importance of the MVC design pattern becomes even clearer when you put yourself in the shoes of the GUI framework developers . The challenge here is that at the time of development of the GUI widgets ( view ) it is not certain which technical data and data structures (model) are to be presented and which technical processes ( control ) are to be implemented. The task of the developer of a GUI framework is therefore to provide an abstraction for the model in the form of interfaces. The illustration clearly shows that individual parts, such as the data storage or the appearance, can be exchanged without any problems.
The MVC design pattern also defines the framework for developers of GUI frameworks. A finished GUI framework includes:
- a presentation ( view ) in the form of implemented GUI widgets ,
- the agreement of an underlying data model in the form of interfaces,
- the agreement of events (english events ) due to user interaction in the form of interfaces and classes and ausimplementierten
- the agreement of events due to model changes in the form of interfaces and out-of-implemented classes.
Interaction between server and browser in web applications
In a broader sense, the MVC pattern for web applications is distributed across servers and browsers and is therefore more complex than the classic MVC pattern. From an abstract perspective, the browser takes on the visible display and direct user inputs, as well as the non-page-specific functions of the controller and view. The server takes care of the specific control of the browser by communicating with it via HTTP .
In the narrower sense, it is only understood to mean the server-side program. A distinction can be made between the web server for static websites and its delegation to special additional programs. The term MVC is used in particular in the context of such additional programs for the web server.
Model
For the browser, the HTML page is the data core of its model. From the perspective of the overall system, it is only a view of the overall model, which is located on the server.
View
The browser takes care of the general functions, such as the display of text, form elements and embedded objects. The display is specifically controlled by the view program part of the server via HTTP response, the main part of the display instruction consists of the HTML page.
Controller
The browser accepts form entries and sends them or accepts the clicking of a link. In both cases it sends an HTTP request to the server. The controller program part processes the data from the HTTP requests and finally triggers the creation of a new view.
JavaScript
The web page may contain program code, usually JavaScript, e.g. B. for the browser-side validation of form entries or control logic for reloading content. This program code can in turn be structured according to the MVC pattern and thus viewed as part of the overall system. It should be noted that the use of client-side logic , which is structured according to the MVC pattern, must be differentiated from an MVC used on the server side. Client and server represent separate subsystems. Such web applications are often implemented according to the single-page paradigm .
Dispensing with the observer pattern
With classic web applications, the browser cannot react immediately to changes in the model on the server according to the classic observer pattern . Every response (HTTP response) to the browser requires a request (HTTP request). One speaks of the request-response cycle. It follows that the observer pattern cannot show its advantages on the server side either. Because it would have meant additional work, it was typically not used. Instead, the controller usually acts as an active mediator between model and view as part of a request-response cycle.
Newer web applications already allow the implementation of an observer pattern. The push technology used here (server push) allows the server to transmit events directly to the clients without a request. Many implementations use so-called long polling (request with delayed response until an event occurs) or the newer web sockets . Some JavaScript frameworks abstract the push procedure and use "the best" procedures made available by the respective browser or server application. Thus it is also possible to introduce the observer pattern in web applications.
The special challenges of hyperlinks and form action
The hyperlink is an outstanding feature of web applications . In a classic GUI application, a button would be created here in the view, the click event of which is linked to the change of view based on its ID in the controller. Although the hyperlink also contains an ID, it is not its own, but the target address of the new view. The same applies to the action address of an HTML form.
Both are controller elements for the user of a browser, but their functional aim is coded in the website. This poses the challenge of separating the pure view from the functionality of the URL when creating the website. The developer of the view shouldn't have to worry about the often complex controller functionality of the URL.
The division of tasks between the view and the controller can be easily achieved using an ID. In analogy to the GUI application, the ID in the controller is linked to the target address. In the view, the URL can be called up via an interface using the ID, or the ID is used as a placeholder for the URL, for example within a template or in the form of link objects in an object tree.
JavaScript libraries and AJAX connection
Here part of the programs of the Model-View-Controller architecture is used on the client side in the browser, while another part, in particular the model, remains on the server. JavaScript libraries provide a variety of widgets. These applications intermediate between web applications and desktop-style widget libraries.
Server-side web applications
The server-side controller usually evaluates the incoming data (request) from the browser. He usually acts as a moderator between the model and the view. On the server side those parts of the program are meant by the view that the HTML code for the response (response) produce. The view often works with HTML templates whose placeholders are replaced with the model's data.
The controller as an intermediary between model, view and web server
A typical functional sequence (without HTTP redirect):
Browser -> HTTP-Request -> Webserver -> Controller
<=> (beliebig häufig) Model oder View
Browser <- HTTP-Response <- Webserver <- Controller
The scope of tasks of the controller can be very variable. In the simplest case, it only assigns model and view. But he can also take on a variety of other tasks. That depends on how active or passive the model and view are in relation to validation, internationalization, business logic, the iterations over the data when it is inserted into the view and in relation to numerous other aspects.
Practice varies depending on personal programming style, web servers, programming languages, frameworks, the use of unit tests and the project requirements. In the case of PHP programs, there is e.g. B. the program interpreter, which already processes the data of the HTTP request and thus in turn takes over partial functions of the classic controller.
HTTP redirect
After changing the model ( create or update ), an HTTP redirect is recommended. This technique prevents the erroneous multiple submissions through a page reload. This also separates the writing of the previous data record from reading the subsequent data record, so that the controllers can be organized more sensibly.
If the validation is successful, the first request, which still deals with the previous data record, has write access to the model. This is followed by a redirect. The second request has read access and already presents the next data record for processing. For the browser user, this feels like a single call.
Browser -> HTTP-Request -> Webserver -> Controller -> positive Validierung -> Model (speichern der Daten nach Validierung) Browser <- HTTP-Redirect <- Webserver <- Controller (danach Redirect durch den Controller) Browser -> HTTP-Request -> Webserver -> Controller -> Model -> View (führt zu neuer Formularanfrage ohne Nutzeraktion) Browser <- HTTP-Response <- Webserver <- Controller (reguläre Response)
In the event of a failed validation, on the other hand, the data record received is directly presented again in the same form for correction. There is no redirect. As a rule, there is no need to query the model again.
Browser -> HTTP-Request -> Webserver -> Controller -> negative Validierung -> View (Formular zur Überarbeitung der Eingaben) Browser <- HTTP-Response <- Webserver <- Controller
Controller cascade
In order to do justice to the scope of the functionality of professional websites, the controller must be structured. The controller is often structured like a cascade. Either a controller is activated on the lowest level of the cascade or the controllers branch out in a tree-like manner in the cascade and lead to a nesting of the resulting view.
Front controllers , controllers and actions are frequently used terms for a 3-tier controller structure. These names reflect the structure of data models and the associated data operations. The front controller branches to a view of the data model that is in focus and is controlled by a controller . The actions as the lowest controller level carry out the data operations for this view, which can be combined with Create, Read, Update and Delete ( CRUD ).
An example of a controller nesting would be a website where the top controller controls the display of the pages. In turn, several MVC blocks can specifically be used at the same time in one side, e.g. B. for a central article and for different context information.
Server-side controllers with the remote presentation model pattern
The remote presentation model is a further development of the MVC pattern . There is already a greater separation between view and controller in the definition of the pattern, which makes it easier in many areas to outsource the controller to the server.
Example: MVC implemented with JavaServer Pages
The above figure shows the MVC model for simple web registration. The user (client) first requests the page register.jsp. He receives a page with an HTML form as an answer. The action is validate.jspspecified in the form . So after filling out the form , the browser sends the entered data to the validate.jsp, which in this case is the control module and checks the entered values. It is only responsible for checking and processing the data. It does validate.jspnot give the user any feedback itself . The control module forwards the control to the corresponding views . In this case either to register.jspif the entries were invalid, otherwise to the ok.jsp. If the control is passed back to the register.jsp, register.jspthe user again shows the form with z. B. an error message. The browser sends the corrected data back to the validate.jsp. If the entries are correct, the data will be transferred to the for storage UsersBean. The control is then ok.jsphanded over to the. This shows the user, for example, a confirmation of success.
See also
- Data Context Interaction is a further development and a rather complementary architecture pattern.
- Smart UI
literature
- Erich Gamma, Richard Helm, Ralph Johnson: Design Pattern. Elements of reusable object-oriented software . 2nd Edition. Addison-Wesley, ISBN 978-3-8273-1862-6 .
Web links
- Portland Pattern Repository - Model View Controller (English)
- Jeff Moore: Model View Controller (English)
- GUI Architectures . Martin Fowler (English)
Individual evidence
- ↑ Kamal Wickramanayake: Is MVC a design pattern or an architectural pattern? ( English ) In: Software View . July 17, 2010. Retrieved December 16, 2016.