Model–view–controller
The English term model view controller (MVC, English model for presentation control) is a model for structuring software development in the three units data model (English model), presentation (English view) and program control ( engl. controller). Some authors classify it as an architectural pattern, other than design patterns. Target of the pattern is a flexible program design, which facilitates subsequent amendment or extension and enables reusability of individual components. It is then possible, for example, to write an application that uses the same model, but one hand implements a Windows or Linux - surface, but on the other hand also includes a web interface. Both are based on the same model, only the controller and view have to be redesigned each.
The MVC concept in 1979, initially for user interfaces in Smalltalk by Trygve Reenskaug described ( Seeheim model), who was then working on Smalltalk at Xerox PARC. It is now regarded but as a de - facto standard for the preliminary design of many complex software systems, some with differentiations and often several divided in each case according to the MVC pattern modules.
- 2.1 widget libraries for desktop applications
- 2.2 interaction between server and browser for Web applications 2.2.1 Model
- 2.2.2 View
- 2.2.3 controller
- 2.2.5 waiver of the Observer Pattern
- 2.2.6 The special challenges of the hyperlink and the form action
- 2.3.1 The controller as an intermediary between Model, View, and Web server
- 2.3.2 HTTP Redirect
- 2.3.3 Controller cascade
Classic architectural patterns
The three components depend depending on the realization of different degrees from each other:
Model (model )
The model contains the data and, if necessary (depending on the implementation of the MVC pattern ) and the business logic. It is independent of presentation and control. The announcement of changes to relevant data in the model is done according to the design pattern "observer". The model is the observed subject, and publishers, ie, " poster ", named.
Presentation (view)
The presentation layer is responsible for displaying the required data from the model and the receipt of user interactions. She knows both their control and the model whose data it presents, but is not responsible for the further processing of user-supplied data. In general, the presentation of changes to data in the model using the design pattern is taught " observers " and can then retrieve the updated data. The presentation often used the design pattern " Composite ".
Controller ( controller)
The controller manages one or more presentations, takes from them contrary to user actions, evaluates them and act accordingly. Each presentation will have a separate control. The control system ensures that user actions are effective, eg by changing the presentation (eg, shifting the window ) or by forwarding to the model (eg acquisition of input data or triggering of processing ). When there were no object orientation, there was a model only of data, and the controller has the data updated often directly. In an object- oriented environment, however, it is better if the model contains the business objects and the control limits itself to pass user input (data and method calls ) from the presentation of the model. The controller further includes mechanisms to reduce the user interaction in the presentation. The control can be the model for a " observer " in some implementations also to manipulate directly when data changes, the view.
Not specified functionalities
Business logic
Since the MVC pattern must be implemented differently in different programming languages, there is no generally accepted definition, where the business logic should be located within the MVC classes. It is - for historical reasons - often programmed in the controller, but is now increasingly implemented in the model because the model then contains all the business objects with all their data and functions, and therefore can be isolated, fast, fully tested and automated. Some MVC frameworks write strictly protected, while the business logic part, others leave this decision to the software developers.
User Input Validation
Similarly, the place for the validation of the user input is not defined. Simple format validations can already be implemented in the view. Validations that need to take greater account of the business logic can be implemented more in the model or in the controller.
Data formatting and internationalization
Also for formatting the raw data and the internationalization is not defined where they occur. For reasons of efficiency, it provides development often that it would integrate this in the model, so you may be limited to the creation of widgets or templates in the view. On the other hand, this aspect of the presentation will be relocated to the model, which is quite contrary to the basic idea. As a variant, it therefore lends itself to also provide this independent functional areas that you must then attributed neither model, view or controller.
Today's implementations
Today's implementations adhere generally do not strictly follow the three components Model, View and Controller. Although many projects define as Model-View- Controller architecture, the term is interpreted very differently. There establish new concepts, such as the Model-View -Presenter and Model- View- Adapter pattern, which attempt to describe the variants precisely.
Widget libraries for desktop applications
As widgets, the individual components of graphical interfaces are referred to as menu items or editor components. Widgets are distinguished in that they combine in addition to the presentation also typical features of the classic controller in a component, such as event handling. Some widgets, such as drop-down lists, you can even have a private internal model, this must then be synchronized with the actual model.
Although the widgets break the solid into three parts, one still speaks nevertheless of a Model-View- Controller architecture. There are also components such as filters for sorting or confirmation dialogs, which can not be clearly categorized into the classic tripartite division.
In applying the widget libraries, the controller can cover part of the classic controller function widgets and is limited to the control of the model and possibly other components of the view.
The importance of the MVC design pattern is even clearer when you put yourself in the position of the developers of GUI frameworks. Here, the challenge is that the time of development of GUI widgets ( View) is not fixed, which presents technical data and data structures ( model) and technical processes ( Control) should be implemented. Thus, the object of developing a GUI framework and to provide an abstraction for the model in the form of interfaces. Can be well seen from the figure that individual parts, such as data storage or appearance, can be easily replaced.
The MVC design pattern defines the framework for the development of GUI frameworks. A finished GUI framework includes:
Interaction between server and browser for Web applications
In a broader sense, the MVC pattern in Web applications on distributed servers and browsers and is therefore more complex than the classic MVC pattern. In the abstract, the browser assumes the visible representation and direct user inputs, and not page-related functions of Controller and View. The server takes care by communicating to it via HTTP to specific control of the browser.
In a narrower sense, however, it refers to only the server-side program. One can differentiate to specific additional programs between the web server for static web pages or its delegation again. The term MVC is used in particular in the context of such add-ons to the web server use.
Model
The browser is the HTML side of the data core of his models. From the perspective of the overall system, it is only one view of the entire model, which is located on the server.
View
The browser takes care of the general functions, such as the appearance of text, form elements and embedded objects. The display is controlled specifically by the view program part of the server via HTTP response whose main part of the representation statement consists of the HTML page.
Controller
The browser accepts form data and sends it off or accepts clicking on a link. In both cases, it sends an HTTP request to the server. The controller part of the program processes the data of the HTTP requests and finally pushes the creation of new views on.
The site may contain program code, usually JavaScript, eg for browser -side validation of form input. This code can once again be divided according to the MVC pattern and thus be regarded as part of the overall system.
Waiver of the Observer Pattern
For Web applications, the browser can not react according to the classic Observer pattern immediately to the changes of the model on the server. Each response ( HTTP response ) to the browser requires a request ( HTTP request ). One speaks of the request-response cycle. It follows that the Observer pattern on the server side its benefits can not play. Because it would only mean an additional expense, it is typically not used. Instead, usually occurs on the controller as an active intermediary between Model and View in the context of a request-response cycles.
The special challenges of the hyperlink and the form action
The hyperlink is an outstanding feature of web applications. In a classic GUI application, a button would be generated here in the view whose click event is linked by its ID in the controller with the change of view. Although the link also contains an ID, but it is not his own, but the destination address of the new view. The same applies to the action address of an HTML form.
Both are for the user of a browser controller elements whose functional goal, however, is encoded in the website. This raises the challenge to separate in the generation of a site the pure view of the functionality of the URL. The developer of the view should have to worry about the often complex controller functionality of the URL.
The division of the view and controller can be achieved simply by means of an ID. In analogy to the GUI application, the ID is linked to the controller with the destination address. In the View URL via an interface based on the ID can be retrieved or the ID occurs as a placeholder for the URL, for example within a template or in the form of Link objects within an object tree.
Here is a 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 available. These applications occupy an intermediate position between Web applications and desktop -like widget libraries.
Server-side web applications
The server-side controller evaluates usually from the incoming data (request) of the browser. He usually occurs in this case as a moderator between model and view. Be the server side under the View those parts of the program understood that generate the HTML code for the response (response). Often the View uses HTML templates whose placeholders are replaced with the data of the model.
The controller as an intermediary between Model, View, and Web server
A typical operating sequence (without HTTP redirect):
Browser -> HTTP Request - > Web - > Controller < => ( As often ) Model or View Browser <- HTTP Response < - Webserver <- Controller The scope of tasks of the controller can be very variable. In the simplest case it assigns only model and view to. But he can also take on a variety of other tasks. That depends on how active or passive to model and view each behavior in terms of validation, internationalization, business logic, the iterations over the data when pasting in the view and in relation to various other aspects.
The practice varies depending on the personal style of programming, web servers, programming languages , frameworks, the use of unit testing and the project requirements. In the case of PHP programs is between the web server and controller, for example, yet the program interpreter, which can feed the data to the HTTP request and thus, in turn, takes over part of the functions of the classical controller.
HTTP redirect
After changing the model (create or update) a HTTP redirect is recommended. With this technique, the multiple erroneous is prevented by sending a page reload. Highlights include the writing of the previous record by reading the following data set is separated, so that the controller can organize meaningful.
Upon successful validation takes the first request, which still treats the previous record, writing on the model to. This is followed by a redirect. The second query accesses read and is already introducing the next record for processing. For the user, the browser does it feel like a single call.
Browser -> HTTP Request - > Web -> Controller -> positive validation -> Model ( save the data after validation) Browser <- HTTP redirect < - Webserver <- Controller (after Redirect by the controller ) Browser -> HTTP Request - > Web -> Controller -> Model -> View (leading to a new form request without user action ) Browser <- HTTP Response < - Webserver <- Controller (regular Response) In a failed validation, however, the received data set is presented directly back to the same form for correction. A redirect is not necessary. As a rule, a re- query of the model is omitted.
Browser -> HTTP Request - > Web -> Controller -> negative validation -> View (form to revise the inputs ) Browser <- HTTP Response < - Webserver <- Controller Controller cascade
In order to meet the scope of the functionality of professional websites just, the controller must be structured. Often the controller is structured cascade. Either a controller is at the lowest level of the cascade triggered or the controller branch in the flow of the cascade tree-like and lead to a nesting of the resulting views.
Front controller, controllers and actions are commonly used terms for a 3-layer controller structure. These designations reflect the structure of data models and associated data operations. The front controller branched this to a view of the data model, which is the focus and is controlled by a controller. The actions as the lowest level controllers perform data operations for this view can be summed up with Create, Read, Update and Delete ( CRUD).
An example of a controller would be a nesting site, in which the supreme controller controls the display of the pages. In a page multiple MVC blocks can be used simultaneously turn specific, eg for a central item and for different context information.
Example: MVC implemented with Java Server Pages
The above figure shows the MVC model for a simple web registration. The user ( client ) requests to the first page register.jsp. He gets a page with an HTML form as a response. As the Action validate.jsp is specified in the form. So the browser sends after completing the form, the entered data to the validate.jsp that the control module is in this case and the entered values checked. It is only responsible for the examination and processing of the data. Even validate.jsp the user is no Feedback. The control module is to control to the corresponding views on. In this case, either register.jsp when the entries were invalid, otherwise the ok.jsp. If the control again passed back to the register.jsp, shows register.jsp the user again to the form with for example an error message. The browser sends the corrected data back to the validate.jsp. If the entries are correct, the data is transferred for storage at the UsersBean. The control is then delivered to the ok.jsp. This example shows the user a confirmation of success.