There is no MVC on the server

    imageMVC nowadays does not use only lazy. Yes, and lazy too, uses a CMS that implements this approach.
    But is it MVC?

    An architecture called MVC appeared in the Xerox PARC research lab when developing programs with a graphical user interface (GUI). It is worth noting that GUI programs appeared in the same place, and having appeared, immediately revealed a new problem to the programming world. The fact is that GUI, in contrast to the command line interface, displays a lot of different information, individual parts of which can be connected and most importantly - allows you to interact with this information.

    When a user interacts with data, they can change, which means that the data associated with them can change. For example, the same line is shown in the text box and in the window title. Rewrite the line - the title should change. The solution "in the forehead": when we understand that the line in the text field has changed, we change the line in the header. But what if the same data is shown in five different places (the data have five representations), in each of which they can change? Then you will have to write code in each handler of the data change event that updates four other views in which the data is displayed. If something changes in at least one view, then all handlers will have to make edits. The code is getting too connected.

    To solve this problem, the MVC architecture was invented.

    The essence of the solution:
    There is no escape from code that changes the view when changing data. He must be. But in one copy. So it must be allocated to a function. And call this function from all handlers. But wait a moment. The words “when the data changes” clearly make it clear that we don’t care what event happened. This means that you can also call the functions for updating the views into a function that will be called upon any event that changes data. As a result, the code updates the view by itself, and to add a new view of the same data, it is enough to add a function call to the data change function.

    Programmers. more specifically, researchers at Xerox PARC loved OOP. And that means they loved what I call the “control lift” - the transfer of the decision to call some code upstream the control flow. This is mainly done by passing an object, which will then be called a method. Instead of making a condition in a function, you can make a condition before calling the function, create one or another object depending on it, and call the function by passing the resulting object as an argument. What does it give? And the fact that it will be possible to change the behavior of a function by passing different objects into it. The function itself will not be changed.

    The same can be done for the function that is executed when the data changes. Let her call the methods of the objects. Then it will be possible to add representations without touching the function. There are many representations, so you need to store objects in an array.

    This is the classic MV * architecture. As for the controller, you can still argue, but in all cases there is data, views and changes in these views when the data changes .

    The bottom line: MVC solves the problem of strong code connectivity, allowing you to separate the model and views using some architecture.

    If you search on a hub, in Google or Yandex, then most of the information is about MVC for web applications. And everywhere it says that when we share data and views, this is MVC. Such a definition is enough to assume that the use of virtually any design pattern that gives us a system bundle into separate parts is MVC.

    UPD: here by web applications I mean such applications, all imaginary MVC of which is focused on the server. For example, here is such a simple MVC system in PHP5

    But wait. Proper use of OOP in any case will give us a system divided into loosely coupled parts.
    In web applications there are no events at all. The HTTP protocol obliges us to kill the application after responding to the request, or pretend that we killed it. So the only event of the web application is its launch with some set of parameters.

    And if there are no events, then the presentation does not need to be updated. They are already rendered at creation.

    In web applications, it is useful to separate the code into business logic, a template, and a controller, but maybe you should call them by their own names, rather than those used in a slightly different programming area?

    UPD: jigpuzzled indicated that a similar separate name for the server architecture already exists: Action-Domain-Responder

    Only registered users can participate in the survey. Please come in.

    Does server MVC need a different name, or are the differences insignificant and confuse no one?

    • 17.8% Definitely needed! 35
    • 12.2% More likely than not, these are two different things. 24
    • 22.4% Rather no than yes, they are different, but they have a lot of promise. 44
    • 47.4% No, it's the same thing, just in different conditions. 93

    Also popular now: