Part 7. Introducing the MVC (Model-View-Controller) pattern

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

• about networking
• about software architecture
• about HTTP/HTTPS
• about the basics of Maven
• about servlets (writing a simple web application)
• about servlet containers

In this article we'll get to know something called MVC. We'll talk about what MVC is, touch on its history, explore the basic ideas and concepts embodied in MVC, take a step-by-step look at how to break up an application into Model, View, and Controller modules, write a small web application using Spring Boot, and, using Spring MVC as an example, see how data is sent from Java code to HTML pages. To understand this material, you need to be familiar with design patterns, especially observer and facade. And be familiar with HTTP requests and responses, understand the basics of HTML, and know what Java annotations are. Grab a cup of coffee and snack, and get comfortable. Let's begin.

History of MVC

The ideas behind MVC were formulated by Trygve Reenskaug while working at Xerox PARC in the late 1970s. In those days, working with computers required a degree and constant study of voluminous documentation. The task solved by Reenskaug together with a group of very strong developers was to simplify an ordinary user's interaction with the computer. It was necessary to create tools that, on the one hand, would be extremely simple and understandable, and on the other hand, would make it possible to control computers and complex applications. Reenskaug worked on a team that developed a laptop computer "for children of all ages" — the Dynabook, as well as the SmallTalk language under the leadership of Alan Kay. That was when the concepts of a friendly interface were laid down. In many respects, the work done by Reenskaug and his team influenced the evolution of the IT sphere. Here is an interesting fact that doesn't apply to MVC directly, but illustrates the significance of these developments. Alan Kay said, "When I first got to Apple, which was in ’84, the Mac was already out and Newsweek contacted me and asked me what I thought of the Mac. I said, 'Well, the Mac is the first personal computer good enough to be criticized.' So, after announced the iPhone in 2007, he brought it up to me and handed it to me. He said, 'Alan, is this good enough to be criticized?' And I said, 'Steve, make it this size as big as a tablet and you’ll rule the world.'" After 3 years, on January 27, 2010, Apple introduced the iPad with a diagonal of 9.7 inches. In other words, Steve Jobs followed Alan Kay's advice almost exactly. Reenskaug's project lasted for 10 years. But the first publication about MVC came to light after another 10 years. Martin Fowler, author of several books and articles on software architecture, mentions that he studied MVC using a working version of Smalltalk. Because there was no information about MVC from the original source for a long time, and for several other reasons, a large number of different interpretations of this concept appeared. As a result, many consider MVC to be a design pattern. Less commonly, MVC is called a composite pattern or a combination of several patterns that work together to create complex applications. But, as mentioned earlier, MVC is actually primarily a set of architectural ideas/principles/approaches that can be implemented in various ways using different patterns... Next, we'll consider the main ideas embedded in the MVC concept.

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 abbreviation that stands for: Model-View-Controller

Disclaimer: MVC is not a design pattern. MVC is a set of architectural ideas and principles for building complex systems with a user interface. But for convenience, in order to not repeatedly say "a set of architectural ideas...", we'll refer to the MVC pattern. Let's start with the simple. What is hidden behind the words Model-View-Controller? When using the MVC pattern to develop systems with a user interface, you need to divide the system into three components. They can also be called modules or components. Call them what you will, but divide the system into three components. Each component has its own purpose. Model. The first component/module is called the model. It contains all the application's business logic. View. The second part of the system is the view. This module is responsible for displaying data to the user. Everything that the user sees is generated by the view. Controller. The third link in this chain is the controller. It contains the code that is responsible for handling user actions (all user actions are handled in the controller). The model is the most independent part of the system. So independent that it must 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 controller. The main purpose of the view is to provide information from the model in a format that the user can consume. The view's main limitation is that it must not change the model in any way. The main purpose of the controller is to handle user actions. It is through the controller that the user makes changes to the model. Or more precisely, to the data that is stored in the model. Here's is the diagram you saw previously in the lesson: From all this, we can draw a logical conclusion. A complex system needs to be divided into modules. Let's briefly describe the steps to achieve this separation.

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

The main idea of MVC is that any application with a user interface can be divided into 2 modules: a module responsible for implementing the business logic, and the user interface. The first module will implement the application's main functionality. This module is the core of the system, where the application's domain model is implemented. In the MVC paradigm, this module is the letter M, i.e. the model. The second module implements the entire user interface, including the logic to display data to the user and handle user interaction with the application. The main goal of this separation is to ensure that the core of the system (the "model" in MVC terminology) can be independently developed and tested. After making this separation, the application's architecture looks like this:

Step 2 Use the observer pattern to make the model even more independent and to synchronize user interfaces

Here we have 2 goals:

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

The following example will help you understand what we mean by synchronization of user interfaces. Suppose we are buying a movie ticket online and see the number of available seats in the theater. At the same time, someone else may be buying a movie ticket. If this other person buys a ticket before us, we would like to see a decrease in the number of seats available for the showtime we are considering. Now let's think about how this can be implemented within a program. Suppose we have our system's core (our model) and interface (the web page for buying tickets). Two users are trying to choose a seat in the theater simultaneously. The first user buys a ticket. The web page needs to show to the second user that this has happened. How is this supposed to happen? If we update the interface from the core, then the core (our model) will be dependent on the interface. As we develop and test the model, we will have to keep in mind the various ways of updating the interface. To achieve this, we need to implement the observer pattern. This pattern lets the model send change notifications to all listeners. As an event listener (or observer), the user interface receives notifications and is updated. On the one hand, the observer pattern lets the model inform the interface (view and controller) that changes have occurred without actually knowing anything about it, thus remaining independent. On the other hand, it makes it possible to synchronize user interfaces.

Step 3 Separate the interface into view and controller

We continue dividing the application into modules, but now at a lower level in the hierarchy. At this step, the user interface (which we separated into a distinct module in step 1) is split into a view and a controller. Drawing a strict line between the view and the controller is difficult. If we say that the view is what the user sees, and the controller is the mechanism that allows the user to interact with the system, you might point out a contradiction. Control elements, such as buttons on a web page or a virtual keyboard on a phone's screen, are basically part of the controller. But they are as visible to the user as any part of the view. What we're really talking about here is functional separation. The user interface's main task is to facilitate the user's interaction with the system. This means that the interface has only 2 functions:

• output and conveniently display system information to the user
• enter user data and commands (communicate them to the system)

These functions determine how the user interface should be divided into modules. In the end, the system architecture looks like this: And this is how we arrive at an application consisting of three modules called the model, view and controller. Let's summarize:

1. According to the principles of the MVC paradigm, a system must be divided into modules.
2. The most important and independent module should be the model.
3. The model is the core of the system. It should be possible to develop and test it independently from the user interface.
4. To achieve this, in the first step of division, we need to split the system into a model and user interface.
5. Then, using the observer pattern, we bolster the model's independence and synchronize user interfaces.
6. The third step is to divide the user interface into a controller and view.
7. All that is required to receiving user data into the system is in the controller.
8. All that is required for delivering information to the user is in the view.

Just one more important thing to discuss before you can drink your hot chocolate.

A little about how the view and controller interact with the model

By entering information through the controller, the user changes the model. Or at least, the user changes the model data. When the user receives information through interface elements (via the view), the user is receiving information about the model. How does this happen? By what means do the view and controller interact with the model? After all, the view's classes cannot directly call the methods of the model's classes to read/write data. Otherwise, we wouldn't be able to say that the model is independent. The model is a set of closely related classes that neither the view nor the controller should have access to. To connect the model to the view and controller, we need to implement the facade design pattern. The model's facade is the layer between the model and the user interface, through which the view receives conveniently formatted data, and the Controller changes data by calling the necessary methods on the facade. In the end, everything looks like this:

MVC: What do we gain?

The main objective of the MVC paradigm is to separate the implementation of business logic (the model) from its visualization (the view). This separation increases possibilities for code reuse. The benefits of MVC are most evident when we need to present the same data in different formats. For example, as a table, graph, or chart (using different views). At the same time, without affecting how views are implemented, we can change how we respond to user actions (button clicks, data entry). If you follow the principles of MVC, you can simplify software development, increase code readability, and improve extensibility and maintainability. In the final article in the "Introduction to Enterprise Development" series, we will look at an MVC implementation built using Spring MVC. Part 8. Let's write a small application using Spring Boot