Is the MVC pattern a dead end for application development?
In this article, I would like to tell why using the MVC design pattern is not enough to create flexible and scalable applications. And also to offer solutions to identified problems.
There's nothing wrong with the Model View Controller template itself. It solves the problem for which it was invented - the separation of the processing logic of the user's request and the presentation logic of information.
')
Prior to the invention of this pattern, the logic for processing a user request and the display logic were closely intertwined in one file. This greatly complicated the support and led to many errors in the system.
Using the MVC pattern is good where the modules are relatively independent of each other. For example, they are called from the main menu. The user works with module A, then opens module B, and so on.
In this case, he must know in what sequence to work with the modules of the system in order to make the necessary changes.
Also, if the process of working with the system has changed (the business or the domain model has changed), then the user can learn a new process without making changes to the user interface of the system.
Everything is good as long as the system is used by a small number of people who can be trained to work with it.
And what if the system is delivered to multiple users?
To simplify the use of the system, you can make sure that she herself knows in what order to work with it and offers the user further steps.
But here lies the cunning use of MVC-template. As shown in the image below, it is tempting to refer directly from the view (View) of module 'A' to the controller (Controller) of module 'B', from module 'B' to module 'C', from module 'C' to module 'D' .
(Or from the controller of the module 'A' to the controller of the module 'B'. Or, even worse, from the controller of the module 'A' to the presentation of the module 'B'.)
The business process will be hard-flashed in 3 views (Views). Agree that it is not very clear. Changing the business process will also be difficult due to the distribution of links across multiple files. And support for several business logic options, where, for example, modules A, C and D will be linked, will have to be implemented via if / else in views.
Unfortunately, this approach is very often used to build applications.
How to restore the former weak connectivity of the system modules, while maintaining the description of the business processes inside it?
To do this, you need to take the configuration of business processes from the modules and place it separately.
Make it so that users and all modules communicate through one main controller.
In this case, the controller will be guided by the configuration, which modules, in what sequence to provide the user for operation.
It is very convenient to use implementations based on finite state machines ( Finite State Machine ) to configure the states of the modules and transitions between them.
Examples of such implementations in the Java world are:
• Spring Web Flow - add-on over Spring MVC .
• ADF Task Flows from Oracle - the implementation is very similar to Spring Web Flow.
• Lexaden Web Flow - implementation for the Vaadin component model.
What else do you know about the implementation of this approach in Java?
Maybe there are similar frameworks for other programming languages?
PPS Details of the implementation of the described solution for Lexaden Web Flow and Vaadin are described in detail in the article: Navigation: an implementation option for an enterprise application
There's nothing wrong with the Model View Controller template itself. It solves the problem for which it was invented - the separation of the processing logic of the user's request and the presentation logic of information.
')
Prior to the invention of this pattern, the logic for processing a user request and the display logic were closely intertwined in one file. This greatly complicated the support and led to many errors in the system.
Using the MVC pattern is good where the modules are relatively independent of each other. For example, they are called from the main menu. The user works with module A, then opens module B, and so on.
In this case, he must know in what sequence to work with the modules of the system in order to make the necessary changes.
Also, if the process of working with the system has changed (the business or the domain model has changed), then the user can learn a new process without making changes to the user interface of the system.
Everything is good as long as the system is used by a small number of people who can be trained to work with it.
And what if the system is delivered to multiple users?
To simplify the use of the system, you can make sure that she herself knows in what order to work with it and offers the user further steps.
But here lies the cunning use of MVC-template. As shown in the image below, it is tempting to refer directly from the view (View) of module 'A' to the controller (Controller) of module 'B', from module 'B' to module 'C', from module 'C' to module 'D' .
(Or from the controller of the module 'A' to the controller of the module 'B'. Or, even worse, from the controller of the module 'A' to the presentation of the module 'B'.)
The business process will be hard-flashed in 3 views (Views). Agree that it is not very clear. Changing the business process will also be difficult due to the distribution of links across multiple files. And support for several business logic options, where, for example, modules A, C and D will be linked, will have to be implemented via if / else in views.
Unfortunately, this approach is very often used to build applications.
How to restore the former weak connectivity of the system modules, while maintaining the description of the business processes inside it?
To do this, you need to take the configuration of business processes from the modules and place it separately.
Make it so that users and all modules communicate through one main controller.
In this case, the controller will be guided by the configuration, which modules, in what sequence to provide the user for operation.
It is very convenient to use implementations based on finite state machines ( Finite State Machine ) to configure the states of the modules and transitions between them.
Examples of such implementations in the Java world are:
• Spring Web Flow - add-on over Spring MVC .
• ADF Task Flows from Oracle - the implementation is very similar to Spring Web Flow.
• Lexaden Web Flow - implementation for the Vaadin component model.
What else do you know about the implementation of this approach in Java?
Maybe there are similar frameworks for other programming languages?
PPS Details of the implementation of the described solution for Lexaden Web Flow and Vaadin are described in detail in the article: Navigation: an implementation option for an enterprise application
Source: https://habr.com/ru/post/169033/
All Articles