Part 7. Introduction to the MVC (Model-View-Controller) Pattern

This material is part of the “Introduction to Enterprise Development” series. Previous articles:

• about the network ;
• about software architecture ;
• about HTTP/HTTPS protocols ;
• about Maven basics ;
• about servlets (we are writing a simple web application) ;
• about servlet containers .

In this material we will introduce you to such a thing as MVC. Let's talk about what MVC is, touch on the history of its creation, understand the main ideas and concepts inherent in MVC, consider step by step how to break an application into Model, View, Controller modules, and also write a small web application in Spring-Boot, and Using Spring-MVC as an example, let's see how data is transferred from Java code to html pages. To understand this material, you need to be familiar with design patterns, especially Observer and Facade. Be familiar with HTTP requests and responses, understand the basics of html, know what annotations are in Java. Sit back, make tea, prepare dessert, salad, main course and first course. We begin.

History of MVC

The ideas for MVC were formulated by Trygve Reenskaug while working at Xerox PARC in the late 70s. In those days, to work with a computer it was impossible to do without an academic degree and constant study of voluminous documentation. The problem that Reenskaug solved together with a group of very strong developers was to simplify the interaction of the average user with a computer. It was necessary to create tools that, on the one hand, would be extremely simple and understandable, and on the other, would make it possible to manage a computer and complex applications. Reenskaug worked on the team that developed the portable computer "for children of all ages" - Dynabook, as well as the SmallTalk language under the leadership of Alan Kay. It was then and there that the concepts of a friendly interface were laid down. Reenskaug's work with his team greatly influenced the development of the IT field. Let us present an interesting fact that does not relate directly to MVC, but illustrates the significance of those developments. In 2007, after the presentation of the Apple iPhone, Alan Kay said: “When the Macintosh came out, Newsweek asked what I thought of it. I said: this is the first personal computer worthy of criticism. After the presentation, Steve Jobs came up and asked: is the iPhone worthy of criticism? And I said, make it five by eight inches and you will conquer the world.” Three years later, on January 27, 2010, Apple introduced the 9.7-inch iPad. That is, Steve Jobs followed Alan Kay's advice almost literally. The project that Rennskaug worked on lasted for 10 years. And the first publication about MVC from its creators was published another 10 years later. Martin Fowler, author of a number of books and articles on software architecture, mentions that he learned MVC from a working version of SmallTalk. Since there was no information about MVC from the primary source for a long time, as well as for a number of other reasons, a large number of different interpretations of this concept have appeared. As a result, many people consider MVC to be a design scheme or pattern. Less commonly, MVC is called a composite pattern or a combination of several patterns that work together to implement complex applications. But in fact, as said earlier, MVC is primarily a set of architectural ideas/principles/approaches that can be implemented in various ways using various patterns... Next, we will try to look at the main ideas embedded in the MVC concept.

What is MVC: basic ideas and principles

• VC is a set of architectural ideas and principles for building complex information systems with a user interface;
• MVC is an acronym that stands for Model-View-Controller.

Disclaimer: MVC is not a design pattern. MVC is precisely a set of architectural ideas and principles for building complex systems with a user interface. But for convenience, so as not to repeat every time: “A set of architectural ideas...”, we will call MVC a pattern. Let's start with something simple. What is hidden behind the words Model-View-Controller? When developing systems with a user interface, following the MVC pattern, you need to divide the system into three components. These, in turn, can be called modules or components. Say what you want, but divide by three. Each component will have its own purpose. Model. The first component/module is the so-called model. It contains all the business logic of the application. View. The second part of the system is the view. This module is responsible for displaying data to the user. Everything the user sees is generated by the view. Controller. The third link in this chain is the controller. It stores code that is responsible for processing user actions (any user action in the system is processed in the controller). The model is the most independent part of the system. So independent that it should not know anything about the View and Controller modules. The model is so independent that its developers may know virtually nothing about the View and the Controller. The main purpose of the View is to provide information from the Model in a user-friendly format. The main limitation of the View is that it should not change the model in any way. The main purpose of the Controller is to process user actions. It is through the Controller that the user makes changes to the model. More precisely, into the data that is stored in the model. Let us give again the diagram that was already shown to you at the lecture: From all this we can draw a completely logical conclusion. A complex system needs to be divided into modules. Let us briefly describe the steps on how to achieve such a separation.

Step 1: Separate the application's business logic from the user interface

The key idea of ​​MVC is that any application with a user interface, as a first approximation, can be divided into 2 modules: a module responsible for implementing the business logic of the application, and a user interface. The first module will implement the main functionality of the application. This module will be the core of the system, in which the application domain model is implemented. In the MVC concept, this module will be our letter M, i.e. model. The second module will implement the entire user interface, including displaying data to the user and the logic of user interaction with the application. The main purpose of this separation is to ensure that the core of the system (Model in MVC terminology) can be independently developed and tested. The application architecture after such a division will look like this:

Step 2. Using the Observer pattern, achieve even greater independence of the model, as well as synchronization of user interfaces

Here we pursue 2 goals:

1. Achieve even greater independence of the model.
2. Synchronize user interfaces.

The following example will help you understand what is meant by synchronizing user interfaces. Let's say we buy a movie ticket online and see the number of available seats in the theater. Someone else can buy a movie ticket at the same time as us. If this someone buys a ticket before us, we would like to see that the number of available seats for our session has decreased. Now let's think about how this can be implemented inside the program. Let's assume we have a system core (our model) and an interface (the web page on which we make a purchase). On the site, 2 users simultaneously select a seat. The first user bought a ticket. The second user needs to display this information on the page. How should this happen? If we update the interface from the system kernel, our kernel, our model, will be dependent on the interface. When developing and testing a model, you will have to keep in mind various ways to update the interface. To achieve this, you need to implement the Observer pattern. With its help, the model sends notifications about changes to all subscribers. The interface, being such a subscriber, will receive a notification and update. The Observer pattern allows the model, on the one hand, to inform the interface (view and controller) that changes have occurred in it, and on the other hand, to actually “know” nothing about them, and thereby remain independent. On the other hand, this will allow user interfaces to be synchronized.

Step 3. Dividing the interface into View and Controller

We continue to divide the application into modules, but at a lower level of the hierarchy. In this step, the user interface (which was separated into a separate module in step 1) is divided into a view and a controller. It's difficult to draw a strict line between a view and a controller. If we say that the view is what the user sees, and the controller is the mechanism through which the user can interact with the system, there is some contradiction. Controls, such as buttons on a web page or a virtual keyboard on a phone screen, are essentially part of a controller. But they are just as visible to the user as any part of the view. Here we are talking more about functional division. The main task of the user interface is to ensure user interaction with the system. This means that the interface has only 2 functions:

• display and conveniently display information about the system to the user;
• enter user data and commands into the system (transmit them to the system);

These functions determine how the interface should be divided into modules. As a result, the system architecture looks like this: So, we have an application of three modules called Model, View and Controller. To summarize:

1. Following the principles of MVC, the system needs to be divided into modules.
2. The most important and independent module should be the model.
3. The model is the core of the system. You need the ability to develop and test it independently of the interface.
4. To do this, at the first step of system segregation, you need to divide it into a model and an interface.
5. Next, using the Observer pattern, we strengthen the model in its independence and obtain synchronization of user interfaces.
6. The third step is to divide the interface into a controller and a view.
7. All that is required to enter information from the user into the system is into the controller.
8. All that outputs information from the system to the user is in view.

There is one more important thing left to discuss and you can drink cocoa.

A little about the relationship between the View and the Controller and the Model

When the user enters information through the controller, he thereby makes changes to the model. At least the user makes changes to the model data. When the user receives information through interface elements (via the View), the user receives information about the model data. How does this happen? How do the View and Controller interact with the model? After all, it cannot be that the View classes directly use the methods of the Model classes to read/write data, otherwise there can be no question of any independence of the Model. The Model represents a tightly interconnected set of classes to which, in a good way, neither the View nor the Controller should have access. To connect the Model with the View and the Controller, it is necessary to implement the Facade design pattern. The model facade will be the very layer between the Model and the interface, through which the View receives data in a convenient format, and the Controller changes the data by calling the necessary facade methods. Schematically, in the end, everything will look like this:

MVC: what is the benefit?

The main goal of following MVC principles is to separate the implementation of the application's business logic (model) from its visualization (view). This separation will increase code reuse. The benefits of using MVC are most obvious in cases where the user needs to provide the same data in different forms. For example, in the form of a table, graph or chart (using different types). At the same time, without affecting the implementation of views, you can change reactions to user actions (clicking a button, entering data). If you follow the principles of MVC, you can simplify the writing of programs, increase the readability of the code, and make it easier to expand and maintain the system in the future. In the final material of the “Introduction to Enterprise Development” series, we will look at the implementation of MVC using Spring-MVC as an example. Part 8. Writing a small application in spring-boot