September 7, 2012 at 03:56MVC is dead, it's time to MOVE
- Transfer
MVC is a phenomenal idea. You have models, independent pieces of states, views that are separate pieces of the UI, and controllers that are separate pieces ... um?
I'm certainly not the first to notice this, but the problem with MVC is that there is too much code being thrust into the controllers.
To fix this, I use a new pattern: MOVE . M odels, O perations, V iews and E vents.
I will describe the details a bit 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 kind of objects, what they have the right to do. I showed them with arrows on the diagram. For example, a view is allowed to listen to events triggered by a model. Operations are allowed to modify models, but models should not indicate representations or operations.
Archetypal model, user object. It has an email, and possibly a name and phone.
In a MOVE application, models only data wrappers. This means that, in addition to getters and setters, they can contain functions that allow you to check "is the user 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."
Common operation for the application: user authorization. These are actually two sub-operations combined together, the first: take the email and password from the user, the second: load the “user” model from the database and check the matching of passwords.
Operations are performers in the MOVE world. They are responsible for changes in your model, show the correct views at the right time, and respond 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, the events are going outbound and the changes are descending.
Interestingly, using operations in this way allows us to consider the application itself as an action that begins 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 when all events are completed.
The login screen is a view that is responsible for displaying multiple text fields for the user. When the user clicks on the login button, the view generates a “loginAttempt” event that contains the user name 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 also is a stream of user interaction in understandable events. The important thing is that the views do not directly modify models; they simply fire up events with operations, and wait for changes by listening to events triggered by the models.
The loginAttempt event fires a view when the user clicks on the login button. In addition, when the login operation has completed, the currentUser model fires events to inform your application that it has changed.
Listening to events is what gives us the inverse of control (IoC) in MOVE (and MVC), in order to enable models to update views without explicitly indicating which views they are updating. This 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 to structure large applications. However, at the time it was coined, new programming techniques became popular. Without closures (or anonymous blocks), event assignment can be tedious; and without deferrables (also known as deferreds or promises), the idea of understanding individual operations as objects would not make much sense per se.
I emphasize: MVC is cool, but it is designed with technologies a decade ago. MOVE is just an update to better use the tools that we now have.
What?
I'm certainly not the first to notice this, but the problem with MVC is that there is too much code being thrust into the controllers.
To fix this, I use a new pattern: MOVE . M odels, O perations, V iews and E vents.
Overview
I will describe the details a bit later, but this diagram shows the basic structure of the MOVE application.
- Models are all that your application should know.
- Operations is all that your application does.
- Views are the intermediary between your application and the user.
- Events are used to securely connect all of these components.
To avoid spaghetti code, it is worth noting that there are recommendations, what kind of objects, what they have the right to do. I showed them with arrows on the diagram. For example, a view is allowed to listen to events triggered by a model. Operations are allowed to modify models, but models should not indicate representations or operations.
Models
Archetypal model, user object. It has an email, and possibly a name and phone.
In a MOVE application, models only data wrappers. This means that, in addition to getters and setters, they can contain functions that allow you to check "is the user 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
Common operation for the application: user authorization. These are actually two sub-operations combined together, the first: take the email and password from the user, the second: load the “user” model from the database and check the matching of passwords.
Operations are performers in the MOVE world. They are responsible for changes in your model, show the correct views at the right time, and respond 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, the events are going outbound and the changes are descending.
Interestingly, using operations in this way allows us to consider the application itself as an action that begins 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 when all events are completed.
Representation
The login screen is a view that is responsible for displaying multiple text fields for the user. When the user clicks on the login button, the view generates a “loginAttempt” event that contains the user name 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 also is a stream of user interaction in understandable events. The important thing is that the views do not directly modify models; they simply fire up events with operations, and wait for changes by listening to events triggered by the models.
Events
The loginAttempt event fires a view when the user clicks on the login button. In addition, when the login operation has completed, the currentUser model fires events to inform your application that it has changed.
Listening to events is what gives us the inverse of control (IoC) in MOVE (and MVC), in order to enable models to update views without explicitly indicating which views they are updating. This 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 to structure large applications. However, at the time it was coined, new programming techniques became popular. Without closures (or anonymous blocks), event assignment can be tedious; and without deferrables (also known as deferreds or promises), the idea of understanding individual operations as objects would not make much sense per se.
I emphasize: MVC is cool, but it is designed with technologies a decade ago. MOVE is just an update to better use the tools that we now have.