It would be hard to build a house without an architectural plan that describes the materials, electricity, room layout, or at least takes into account the geological properties of the land on which the building is supposed to stand. Each of these aspects is extremely important, because if ignored, it may lead to a serious disaster. The applications we build, much like buildings, can fall apart if they are not planned well. Adding more elements without a plan and without an idea will create chaos and uncontrolled code growth, and over time it will block further development of our project.

Fortunately, architecture is an area that has also been taken care of in IT. We have many different approaches at our disposal, and each of them will be good for different use cases. Today I will try to discuss one of the most popular architectural patterns, one that had a huge influence on how web applications developed over the years. Please welcome MVC.

In the Laboratory

The Xerox corporation has appeared many times in my stories. This case is no different. In the late 1970s, Norwegian programmer Trygve Reenskaug was working at Xerox on the object-oriented language Smalltalk. As part of that work, he developed the concept of the MVC pattern. MVC was meant to help solve the problem of users controlling large and complex data sets. Trygve originally called the proposed approach Model-View-Editor, but over time he changed the name to Model-View-Controller, which has stayed with us to this day.

The main idea of MVC is to divide the whole application into three independent layers that organize the system architecture. Each layer forms a logical whole. Changes in any one layer should not force huge changes in the remaining layers. So the question appears: what layers are we talking about? As the name suggests: Model (the data model), View (the view, the interface, meaning what the user sees), and Controller (the logic).

Today MVC is one of the most popular architectural approaches used in web-development. Frontend frameworks that use MVC include Ember, Angular.js, and Backbone. The solutions I mentioned are no longer as popular as they once were. Today, on the frontend, component architecture or MVVM is used more often. Why did that happen? More on that later in the story.

On the backend, MVC is still doing quite well. We can find it in ASP.NET, Django, Laravel, and many others. Let us try to discuss the individual layers and their role in the application.

Model

The model is the representation of data in our application. The model's main job is to define what elements a given object is built from and to communicate with the database (operations such as writing, modifying, reading, and deleting data from the database). For example, if we are building an application that sells vegetables, the model will define elements such as customer, vegetable, and order. Each of these elements will contain information about properties that are necessary from the perspective of business logic. That is where the model's role ends.

The model itself cannot communicate with the view directly. The intermediary between these two layers is the controller layer. We distinguish two types of model: passive model and active model. A passive model is one that never changes its state without the controller being involved. In an active model, on the other hand, the state may change on its own. In that case, such a model should have functionality implemented for notifying the appropriate controller about the change that occurred.

Controller

The intermediary role means that the controller is responsible for the correct flow of data in the application. It is the controller that handles user requests. So if the application user filled in a form that was sent, for example, using the HTTP POST method, then it is the controller that will receive this request and process it further. It will decide what to do with it next: modify the view, change the model state, or perhaps pass control to another controller.

In addition, the controller is responsible for handling business logic. We can confidently say that the controller is the brain of the entire application.

View

MVC was created mainly to support applications using a GUI (Graphical User Interface). View, meaning the view, is responsible for handling the user's work: displaying data, handling events, and passing them to the controller. In other words, it is the layer thanks to which everything looks nice and works (at least from the user's perspective, it should).

And that is the whole philosophy of MVC. The main assumption is to isolate individual application layers and use an intermediary layer to manage the flow of information. This minimizes dependencies between individual system elements, while the views themselves can be developed dynamically without much involvement from the logic and the model, which ultimately lowers the cost of extending the project.

About the Good and Bad Sides of MVC

I have already written about many of the good sides above, so to summarize, MVC:

• focuses on simplicity; the division into three layers is very clear and straightforward,
• makes views easy to develop, because the logic layer does not change as often as the presentation layer, and because they are separated, we can develop them independently,
• does not make the model dependent on the view; the model is always independent, and different views can use one model and present the data in any way they need.

Nothing is black and white, though. If there are good sides, there must also be bad ones. They mainly result from the advantages listed above. Since the model is independent of the view and can be implemented many times at a low cost, changing the model becomes harder. Every model change will require finding all the views that use it and adjusting them.

Extracting logic into a separate layer while also keeping part of the logic in the view (the part related to communication) increases complexity and makes testing harder, especially view testing.

3 + 2 = 1

It often happens that MVC can also be treated as a compound pattern, meaning a pattern created by mixing several other design patterns. The most popular division points to three patterns: composite, strategy, and observer. The Gang of Four adds two more patterns to this set: factory method and decorator.

I will not describe here what each of the patterns above does. What matters, however, is that we can find them when using MVC in each of the three layers.

In case someone does not know who the Gang of Four are, let me add that it is a group of four authors: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, who in 1994 wrote a book about design patterns that is considered in the IT world to be one of the better books touching this topic. To this day, it is an Amazon bestseller.

Facebook and MVC

Before 2014, Facebook was built on the MVC architecture. However, the company decided to move away from it as the application grew. This was mainly because many two-way connections appeared between views and controllers due to the use of two-way data binding, which I wrote about here. This approach meant that in Facebook's case, MVC was not a scalable solution. Two-way data flow covers many-to-many relationships, which are hard to track and maintain.

This was especially visible when Facebook introduced chat into its application. Chat displayed information about unread messages even when those messages had already been read earlier (or even marked as read). For a long time, Facebook developers fought with this bug, but they were not able to fix it. In the end, the problem was solved by giving up MVC architecture in favor of the one-way Flux architecture.

Facebook's case shows that choosing an architecture and using it skillfully within an application can be difficult. Sometimes we have to back out of decisions we once made, even if the change is huge.

Is This the End of MVC?

MVC was also used on the frontend for many years. The frontend environment, however, decided to move away from MVC in favor of MVVM or simply component architecture with the addition of Flux or Redux. MVC is often criticized for too much dependence of the view on the model, which means that changes in the model always cause changes in the view.

In addition, in frontend applications rendered on the client side, controllers are even more dependent on the view, which Facebook experienced in 2014. Models are also overloaded because they store information about the user interface state (products, articles, the vegetables mentioned earlier) and about the state of the application itself (view settings, theme color, selected language). With tasks defined this way, the Single Responsibility Principle (one of the five SOLID principles) is broken. The model manages different kinds of state and lacks separate mechanisms for handling them, while the controller deals with events coming from the view and with business logic.

Today MVC is still one of the most popular standards for building scalable web projects. The frontend world pushes it away, modifies it for its own needs (as in MVVM, for example), but that does not change the fact that among programmers it is still one of the simplest design schemes to implement in applications, and it is worth knowing.

Summary

MVC is one of the oldest architectures available. It is worth getting familiar with it, especially because it is widely used in the world of web-development. If we break it down into parts, it turns out that underneath we can find many interesting design patterns.

Modern architectural solutions are more often connected with more advanced schemes than MVC, often referring to newer approaches based on specialized technologies or on the domain. Even so, MVC is a solid architecture that, when used well, will work very well in many cases and will help us better understand those more modern approaches.