MVC is dead, it's time MOVE
MVC is a phenomenal idea. Do you have models, separate pieces of states, views that are separate UI pieces, and controllers that are separate pieces ... uh?
I'm certainly not the first to notice this, but the problem with MVC is that they push too much code into the controllers.
To fix this, I use the new pattern: MOVE . M odels, O perations, V iews and E vents.
I will describe the details later, but this diagram shows the basic structure of the MOVE application.
To avoid spaghetti code, it is worth noting that there are recommendations, what type of objects, what they are entitled to do. I showed them with arrows on the chart. For example, a view is allowed to listen to events triggered by a model. Operations are allowed to change models, but models should not point to views or operations.
')
Archetypical model, the object "user". It has email, and possibly a name and phone number.
In the MOVE application, the data wrapper model only. This means that, in addition to getters and setters, they may contain functions that allow you to check "is this a user's password?", But do not contain functions that save data to the database or load them into a third-party API. This is the work of "operations."
The usual operation for the application: user authorization. These are actually two sub-operations combined together, the first: to take an email and password from the user, the second: to load the “user” model from the database and check the correspondence of passwords.
Operations are performers in the world of MOVE. They are responsible for changes in your model, show the right ideas at the right time, and react to events triggered by user interaction. In a well-built application, each sub-operation can be started regardless of its parent; that is why, in the diagram above, events follow in outgoing, and changes in descending.
Interestingly, using operations in this way allows you to consider the application itself as an action that starts when the application starts. It generates as many sub-operations as it needs, where simultaneously existing sub-operations are launched in parallel, the program exits upon completion of all events.
The login screen is a view that is responsible for displaying several text fields for a user. When a user clicks on the login button, the view generates a “loginAttempt” event that contains the username and password entered by the user.
Everything that the user can see or interact with must be implemented in the view. It not only displays the state of your application in an understandable form, but is also a stream of user interaction into understandable events. It is important that views do not change models directly, they simply trigger events with operations, and wait for changes while listening to events triggered by models.
The "loginAttempt" event triggers a view when a user clicks on the login button. In addition, when the login operation has completed, the “currentUser” model triggers events to inform your application that it has changed.
Listening to events is what gives us the inversion of control (IoC) in MOVE (and MVC) in order to allow models to update views without explicitly indicating which views they are updating. It is a powerful abstraction technique that allows components to be connected together without interfering with each other.
I do not want to be misunderstood, implying that MVC is bad; For the past decade, it has been an incredibly successful way of structuring large applications. However, at the time when it was invented, new programming techniques became popular. Without closures (or anonymous blocks), assigning events can be tedious; and without deferrables (also known as deferreds or promises), the idea of ​​understanding individual operations as objects would not in itself have much meaning.
I emphasize: MVC is cool, but it is designed with a decade-old technology. MOVE is just an update for more efficient use of the tools that we now have.
What?
I'm certainly not the first to notice this, but the problem with MVC is that they push too much code into the controllers.
To fix this, I use the new pattern: MOVE . M odels, O perations, V iews and E vents.
Overview
I will describe the details later, but this diagram shows the basic structure of the MOVE application.
- Models are all your application needs to know.
- Operations are all that your application does.
- Views is the intermediary between your application and the user.
- Events are used to safely connect all of these components.
To avoid spaghetti code, it is worth noting that there are recommendations, what type of objects, what they are entitled to do. I showed them with arrows on the chart. For example, a view is allowed to listen to events triggered by a model. Operations are allowed to change models, but models should not point to views or operations.
')
Models
Archetypical model, the object "user". It has email, and possibly a name and phone number.
In the MOVE application, the data wrapper model only. This means that, in addition to getters and setters, they may contain functions that allow you to check "is this a user's password?", But do not contain functions that save data to the database or load them into a third-party API. This is the work of "operations."
Operations
The usual operation for the application: user authorization. These are actually two sub-operations combined together, the first: to take an email and password from the user, the second: to load the “user” model from the database and check the correspondence of passwords.
Operations are performers in the world of MOVE. They are responsible for changes in your model, show the right ideas at the right time, and react to events triggered by user interaction. In a well-built application, each sub-operation can be started regardless of its parent; that is why, in the diagram above, events follow in outgoing, and changes in descending.
Interestingly, using operations in this way allows you to consider the application itself as an action that starts when the application starts. It generates as many sub-operations as it needs, where simultaneously existing sub-operations are launched in parallel, the program exits upon completion of all events.
Representation
The login screen is a view that is responsible for displaying several text fields for a user. When a user clicks on the login button, the view generates a “loginAttempt” event that contains the username and password entered by the user.
Everything that the user can see or interact with must be implemented in the view. It not only displays the state of your application in an understandable form, but is also a stream of user interaction into understandable events. It is important that views do not change models directly, they simply trigger events with operations, and wait for changes while listening to events triggered by models.
Developments
The "loginAttempt" event triggers a view when a user clicks on the login button. In addition, when the login operation has completed, the “currentUser” model triggers events to inform your application that it has changed.
Listening to events is what gives us the inversion of control (IoC) in MOVE (and MVC) in order to allow models to update views without explicitly indicating which views they are updating. It is a powerful abstraction technique that allows components to be connected together without interfering with each other.
Why now?
I do not want to be misunderstood, implying that MVC is bad; For the past decade, it has been an incredibly successful way of structuring large applications. However, at the time when it was invented, new programming techniques became popular. Without closures (or anonymous blocks), assigning events can be tedious; and without deferrables (also known as deferreds or promises), the idea of ​​understanding individual operations as objects would not in itself have much meaning.
I emphasize: MVC is cool, but it is designed with a decade-old technology. MOVE is just an update for more efficient use of the tools that we now have.
Source: https://habr.com/ru/post/147038/
All Articles