MVC: what is it and how it relates to the user interface

Recently, I talked a lot about MVC (Model-View-Controller) with a number of programmers who hold positions at various levels in software companies. I met a lot of misunderstanding and now I want to share my thoughts on this issue. MVC is a very abstract thing, and this is the main cause of misunderstanding – an underestimated degree of abstractness.

It manifests itself in the following: a programmer, as a rule, works within the framework of one paradigm (OOP our everything) and looks at the world through it. And when he hears, for example, “controller” – represents the class. And this particularity is a class, or not a class, or a collection of objects or procedures, it does not matter. The understanding is also distorted by the specific MVC framework. I’ll try to influence it.

What is MVC?

So, MVC is about the user interface (UI). Not necessarily graphic UI, voice control is also good. Do not forget that a program may not have a user interface, it may have a program interface (API) or it may not have any at all and still be useful.

But if we have a user, then there must be a user interface. What is the interface? This is the adjacent boundary between the two systems. In our case: on the one hand – the program, on the other – the user. Here they are.

The program is completely abstract, any subject code. She knows how to do something useful, and the user has needs that can be met with this program. Then there are pieces of logic that “know” how, using this program, directly do what the user wants. Pieces – not subject, subject logic in the program. They relate more to the user with his specific needs and are combinations of calls and program calls.

Use cases

As an example, imagine a terminal for trading on the exchange. The terminal user submits an application in which it indicates that it wants to buy shares of the Random company in the amount of 20 pieces at a price of $25 per share. It also indicates that the application is valid for four hours, and from which of its accounts to debit the money, in case of a successful transaction.

A tangible number of attributes. It takes some time, and he understands that at this price it will not be possible to buy and is ready to raise the price to 1,550 rubles, leaving all other values. Then he chooses this application, clicks the “change” button, indicates a new price, yes. It’s comfortable.

But on the exchange you can not change the application, in the subject area, there is no such thing. The application can only be set and cancelled. In order to give the user an opportunity to change the application in one click, one has to memorize old values, remove the application, give to edit what we have remembered and make a new application. Such a combination. But for the user, it looks like one simple action: changing the application. This is called a use case.

Let’s complete our diagram with the use cases.

Also, you need to provide the user with an opportunity to run these use cases and get results. These can be buttons and other graphics I/O elements, gestures, identification and speech synthesis. Thus, it can be any data and commands sharing option. Finally, here is it:

The user pulls one of the use cases, which, in turn, manipulates the program. The program publishes the result or changes in its condition.

So where is MVC here?

Everything left is to distribute the names to the created components.

When a model publishes changes, it doesn’t care for anyone, it doesn’t know anything about View. Instead of or together with View, there may be another subsystem on that end.

Now a few particulars.

It was a classic version of MVC – Active Model. It also happens that the model does not notify about changes. Then the controller takes on this responsibility. He knows what manipulations he makes on the model, and, obviously, he knows what changes in the state of the model can follow. This is the Passive Model.

And one moment. The division of the code into objective and non-objective is conditional and depends on how pedantically we want to model the subject area. Sometimes it is a rational decision – to include some sort of code in the model. Perhaps this will reduce the amount of code as a whole and simplify it.