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.

Here’s the 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.

To solve 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.



Here some 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>

Benefits are obvious. Views and controllers of module have not been touched but the application behavior has changed.
The major application logic is described in one file. That is much more convenient than if it has been spread out among several files, isn’t it?

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. 

In Java 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?

Lexaden
Easy to keep focus on business needs