Does MVC pattern have any future?
In this article I would like to cover the aspects of usage of MVC pattern to build up robust and flexible applications. And also to indicate possible problems of its usage and figure out how to solve detected problems.
Here we consider possible variant of usage of MVC Model 2 or Model-2 patterns for development of Java web applications.
Model View Controller
allows a clear separation of user request processing logic (Controller) from logic
responsible for presentation (View).
Not using this
approach you can come to the fact that request processing logic and display logic
will be tightly intertwined in java code. That will lead to the so called spaghetti. It happens
when during user request processing the response is being formed at the same
time. It may not let you test user processing
and presentation logic properly and will lead to imminent bugs.
MVC-pattern can be used differently to build up web applications. Below one of the options is presented with its advantages and disadvantages.
You can organize
the system into modules that are loosely-coupled with each other. Loose
coupling provides certain advantages in system design and operation such as
modules reuse. The modules can be tested separately from the system. It is
relatively easy to replace, add or remove modules during operation without
making major changes to the system.
In this case modules are connected only at the level of domain models. Controllers and views of different modules will not be aware of each other. To work with the system users call functions of each module step by step - A, B, C, D. Entity created in module A becomes available in module B. Entity created in module B as well as entity created in module A become available in module C, etc.
In such system user is supposed to be clearly aware of the process of working with the system: what modules in what order to work with to finish up the task.
Each new user should pass a special training how to use the system. In fact all of that restrains the mass use of the system.
solution comes up – to connect modules for instance by links. By clicking the link in module A appropriate
controller of module B is called. By the link in module B controller from
module C is called and so on.
Now users are happy because they don’t need to keep in mind in what order to work with the system. But in this case system support becomes more complicated since modules become tightly-coupled. The work with the system is distributed among a number of different files. Any modifications require full system retesting.
Quite often such problems come up during application development. The reason is that it is hardly possible to see the essence of things from all of those details. Thinking in terms of Model View Controller is easy to go beyond the specific module and turn the whole system into one big monolithic module.
this problem, you need a mediator- Root Controller and Front Controller and to
make sure that all modules communicate through it. Root Controller will take
from configuration what module under what conditions to provide the user with.
explanation is required since user should work with the system asynchronously
and Root Controller should keep information about active module. To provide loose-coupling
between modules they should communicate by means of events. Configuration will
determine what modules under what conditions to provide the user to work with.
<?xml version="1.0"?> <application initial="A"> <view id="A"> <on event="next" to="B"/> </view> <view id="B" > <on event="previous" to="A"/> <on event="next" to="C"/> </view> <view id="C"> <on event="previous" to="B"/> <on event="next" to="D"/> </view> <view id="D"> <on event="previous" to="C"/> <on event="finish" to="finish"/> </view> <on event="cancel" to="cancel"/> <final id="finish" /> <final id="cancel" /> </application>
Using configuration it is possible to change system behavior. For instance to leave only 2 steps out of 4:
<?xml version="1.0"?> <application initial="A"> <view id="A"> <on event="next" to="D"/> </view> <view id="D"> <on event="previous" to="A"/> <on event="finish" to="finish"/> </view> <on event="cancel" to="cancel"/> <final id="finish" /> <final id="cancel" /> </application>
obvious. Views and controllers of module have not been touched but the
application behavior has changed.
I would like to draw your attention that configuration is presented in XML format just for good visibility. Quite possible to implement such configuration in Domain Specific Language that provides configuration validation on compile time.
there are some frameworks already implementing this approach to avoid tight
coupling between application modules. As you may already know these solutions
are based on finite state machines.
· Spring Web Flow – quite good to use it in applications based on Request/Response model.
· Lexaden Web Flow – created especially for rapid development of flexible enterprise AJAX applications based on Vaadin component model.
The main difference of those frameworks is that Spring Web Flow is tightly coupled to HTTP Request/Response model and that’s why it’s not so easy to use it with AJAX component frameworks such as Vaadin. We have to refresh the whole page ignoring benefits of AJAX within component framework.
Lexaden Web Flow allows you to use the whole power of this approach at the level of AJAX requests. Together with Vaadin component model it allows you to create flexible, scalable, reliable enterprise applications.
What do you think about this article?