Model View Controller (MVC) usage experience, conclusions

Recently I completed my first project implemented according to the Model-View-Controller concept (MVC, although from a technical point of view, CMV would be more correct). In the article I suggest the reader to get acquainted with my personal impressions of the concept.

Note

Everything written in the article is my personal opinion. You, as a reader, do not have to agree with him.
The purpose of the article is to acquaint the reader with another opinion regarding the common concept.

My way to MVC

Some time ago, I decided to make my blog. Having fidgeted with WordPress for a while, I came to the conclusion that “there is no fish there” (and today, looking at the statistics of requests to the site, I believe that the rejection of WordPress was the right decision). In general, after analyzing the totality of external factors (my knowledge, the necessary time for development, additional maintenance costs, etc.), I decided to develop everything on my own, from scratch. And since now my hands were untied (in choosing the mechanisms of the program organization), I decided to try out the widely advertised MVC concept on my own (in previous projects I used a modular approach).
')

My understanding of MVC

Since the technical documentation found by me uses quite abstruse formulations (such as “uses the model and the presentation to realize the necessary reaction”), I consider it necessary to write my own understanding of the MVC concept (so that no misunderstandings arise).
So, according to the concept of MVC, an application should consist of 3 fundamental logical parts: controller (controller), model (model), view (view / display). The controller block - converts user actions (in this context, the user is not necessarily a person) into the input parameters for the Model and transfers control to the Model. The model block implements all the logic of the program and prepares data for display. Block view - visualizes the results of the program. Every user action always starts the chain controller-> model-> view.
Let's write out the functions of each block in more detail, controller:

• loads environment variables (POST / GET variables, command line parameters, URL parameters, etc.);
• Performs primary processing of environment variables (checking the types of variables, their presence, setting default values, etc.);
• implements control mechanisms for emergency situations;
• implements logging mechanisms (not authentication, but logging).

Model:

• performs a final check of incoming parameters (validity of values, ranges, etc.);
• implements interaction with data storage systems (databases, files, SOAP, etc.);
• implements the logic of the program;
• prepares data for visualization.

View:

• organizes mechanisms for visualizing the results of the program.

At the moment, the project has moved from the “development and implementation” stage to the “maintenance and expansion” stage, and at this stage I want to note the following advantages and disadvantages of the MVC concept (I do not pretend to objectivity, personal observations).

Disadvantages of the MVC concept

1. The need to use more resources. The difficulty is due to the fact that all three fundamental blocks are completely independent and interact with each other exclusively by transferring data. The controller should always load (and, if necessary, create) all possible combinations of variables and transfer them to the Model. Model, in turn, must load all the data for visualization and transfer it to the View. For example, in the modular approach, the module can directly process environment variables and visualize data without loading them into separate memory sections.
2. The mechanism of program division into modules is complicated. In the concept of MVC, the presence of three blocks (Model, View, Controller) is rigid. Accordingly, each functional module must consist of three blocks, which, in turn, somewhat complicates the architecture of the functional modules of the program.
3. The process of expanding the functionality is complicated. The problem is very similar to the above. It is not enough just to write a function module and connect it in one place of the program. Each functional module must consist of three parts, and each of these parts must be connected in a corresponding unit.

MVC concept benefits

1. Unified system concept. The undoubted advantage of MVC is a single global application architecture. Even in complex systems, developers (both those who developed the system and newly joined ones) can easily navigate through the program blocks. For example, if an error occurred in the logic of data processing, the developer immediately discards the 2-blocks of the program (controller and view) and investigates the 3rd (model). I have repeatedly wondered how much the localization of problems has been simplified.
2. Simplified debugging mechanism of the application. Since the entire visualization mechanism is now concentrated in a single program block, the mechanisms for the optional output of graphic elements have been simplified. I can not assess how applicable this statement is to the programming of classical applications, but in Web programming this architectural feature has become an undoubted advantage.

findings

The overall impression of using the MVC concept was positive. Those difficulties that attracted my attention - they are more psychological (this has always been the case, and now it's different). At the same time, the question remains to me how much the MVC concept can be applied in developing ordinary applications (for example, for Windows). On the vskidku like you can, but not the fact that it will be optimal.
Well, the most important question: will I use the MVC concept in my next projects? Answer: I think so.