Is it MVC?

    Good afternoon!

    Today I want to share with you my thoughts on the architecture of information systems, in particular, the diverse approaches to the distribution of logic, data and display, traditionally attributed to MVC.

    Over the past two weeks, in conversations with a dozen familiar programmers, I found out that everyone imagines MVC in completely different ways. It comes to diametrically opposing views, but for some reason, everyone insists that it is MVC and that it should look that way, and are fully confident that everyone sees it that way.

    What is the difference? To understand this, let's formulate the tasks of MVC:

    1. Screen the model- that is, to make sure that the model does not “know” anything about the technical implementation of the application, the user interface, network protocols, working with the database and even the system architecture. The model should reflect the subject area and be outside of technology.

    2. Separate the presentation layer - means to be able to create several views for the same model, which can exist in parallel, for example, for different user devices, browsers, mobile platforms and window applications. This also makes it possible to parallelize the work by introducing a division of labor with GUI programmers and even designers who can make display templates, but should not get into the code.

    That's all, there are two parts of the system, and we need to make sure that they are less dependent on each other. And since the model should not “know” about the presentation, a third entity is introduced - a controller that “knows” both parts of the system and, roughly speaking, can make calls to them. This is where the confusion begins.

    First, where opinions differ, this is where the application logic should be located. Some put all the logic in the model and make a thin layer of the controller, while others, on the contrary, increase the functionality of the controller, leaving only data in the model. In this case, the controller is filled with classes whose names indicate their belonging to the subject area with the prefixes “Manager”, “Dispatcher”, “Logic”, “Controller”, etc. In fact, there are two options: make the controller the core of the system or make it a proxy layer. But there is also a class of tasks (graphical applications with advanced visualization and games), when the representation is so closely connected with the model that the model contains directly the coordinates, behavior and rendering features, and the controller evaporates. This is called MVVM (Model-View-ViewModel), and as it turned out later,

    The second disagreement is over who should work with the database. Someone puts data requests into the model and says that the model itself must know how to “rise” and save it, others put calls to the DBMS into the controller, and others - allocate another component of the system specifically for working with the database, calling it “ Repository ”,“ Repository ”or even“ ORM ”(that is, object-relational mapping). At the request of the controller, ORM generates a model object and, at its request, ORM can save, modify or synchronize the object with the database.

    And the thirdthe difference is where the interface logic should be implemented, which can only be forgotten in the simplest applications. It can be placed in the presentation layer, but for some it seems not conceptual and they find a place in the controller for it. Therefore, with each movement in the user interface, control falls into the controller. For web applications, this leads to page overloads or constant AJAX requests, since the view itself is not able to respond even to the smallest user actions.

    Finally lastthe point of disagreement is manifested in the confusion of the MVC architectural approach with a three-tier architecture: DBMS-Application Server-Client, which has long been entrenched in the minds, especially among the older generation of developers. In fact, MVC and three-link are not the same thing, but they can exist in parallel. For example, in web applications, all three links can be located on the server and only the rendering of the finished page will occur in a web browser. Another option, and it is more modern, when a client-side JavaScript application is launched in the browser, fully or partially implementing the presentation layer. For these purposes, even JavaScript templates have appeared. But we won’t be able to completely transfer the presentation to the browser on the client side, unless, with the complete rejection of HTML and reducing the page to a single JavaScript connection tag. This is extremism,

    Thus, everyone imagines MVC in different ways, and they implement completely different architectures under this sign, we will arbitrarily denote them: Mvc, MVc, mvC, mVC, etc. All this happens because the task itself is fraught with contradiction. To make the model and presentation independent, you do not need to separate data, logic, and mapping at all. These are completely different things. Each separated link will still contain data, logic and mapping, for example: data logic in the database and stored procedures; display logic in the user interface; business logic or model logic; data is contained in both the user interface and the controller; an interface is not only an interface, but also a user interface between the model and the controller.

    So, it’s impossible to separate the model from the controller? It is possible, but for this it is necessary to abandon the separation of data, logic and representation. Paradoxically, MVC only works if Model, View, and Controller are implemented at different levels of abstraction. Model- It must contain both data and the logic of the domain and in competent object-oriented programming, it must coincide with the concept of “domain object” or “display of the real world object”. Model is, first of all, modeling, and this includes an information model, a logical model, and even a visualization model, for some tasks. The domain object does not need to know how it is stored in the database, transmitted between program modules and over the network. It runs in the application, as in a virtual machine, and, ideally, should be portable even between systems. Just for this, I insist on writing the model logic in scripted, interpreted languages ​​(my personal preference is JavaScript). This does not exclude the speed of the model, because that the script can be compiled into native language code or immediately into bytecode and cached for long periods of time. As for the user interface, part of the model will always be contained in it, and if it is in JavaScript, we can run things like business logic, validation and the model, partly on the server, and partly on the client. Some parts are only on the client or only on the server, and some are both there and there, without rewriting them many times. What then is View? A Some parts are only on the client or only on the server, and some are both there and there, without rewriting them many times. What then is View? A Some parts are only on the client or only on the server, and some are both there and there, without rewriting them many times. What then is View? AView is a renderer (for web applications - a browser), plus a library of visual components (excuse the old delphist), plus templates and styles.

    What remains to the controller? Controller- This is the virtual machine in which the object of the subject area is launched. The controller does not have to correspond with each application, it is the Application Framework (application platform). Moreover, part of the controller works on the server side, and part in the browser. The controller takes data from the model on the server side and transmits over the network. On the other hand, in the browser, the controller catches the data and transmits them for visualization, and also deploys the part of the model that is needed on the client so as not to drive data over the network with every user action. Where did I get this from? And remember the seven levels of the ISO / OSI model, in addition to vertical interaction between layers, it also has horizontal (logical) interactions - protocols. On different sides of the connection, the transport logically interacts with the transport, and the model should interact with the model, and the framework with the framework (see. Fig.). Moreover, they have different levels of abstraction in the vertical interaction, and in the horizontal, they are on the same level.



    Thus, we have a model Storage-Model-Application-Renderer-Template-Model, which, of course, is well-shortened in SmartModel, which reflects the meaning of the approach. But this is already from the field of metaprogramming, and I will talk more about this in a separate article.

    I do not claim authorship (these ideas have long flown in the air), nor that this is the only and most correct approach to the architecture of information systems. Totally, I have not yet seen this implemented somewhere. This is more of an action plan that I outlined for myself than a description of the finished platform, however, I have already implemented a lot of fragments and will soon hand it over to the public in open source.

    Thanks for attention.

    Also popular now: