Ext JS 5: MVC, MVVM, etc

The Sencha Ext JS framework has become an industry standard for developing enterprise web applications with an extensive library of widgets, powerful support for working with data, and a rich set of development tools. Since the release of Ext JS 1.0 in 2007, much has changed in our industry, and web applications have undoubtedly become bigger and more complex than ever before.

In 2010, Sencha released Touch 1.0, giving the industry the first JavaScript framework with MVC support, aimed at resolving the architectural problems faced by large web applications. We then applied the same approach to Ext JS 4.0 in 2011, helping to organize code in the new world of corporate web applications.

Considering that the architecture of an application is largely both the adherence to structure and consistency, and the use of modern capabilities of the framework, then building a good architecture provides several important advantages:

• All applications work on the same principles that need to be remembered once.
• Once the principles are the same, it makes it easy to reuse code between applications.
• You can use development tools to create optimized versions of applications for debugging or production release.

Touch 1.0 and Ext JS 4.0 have identified some best practices on how to structure your applications using MVC, and Ext JS 5 takes this concept to a new level by adding support for the MVVM architectural pattern. Despite the fact that MVC and MVVM are actually very similar, the use of MVVM provides some specific advantages that significantly reduce the amount of application logic.
')
It is important to realize that Ext JS 5 is fully backward compatible with MVC-based applications. To understand what has changed and what has not, let's take a deeper look at MVC and MVVM.

What is MVC?

Model-View-Controller ( MVC ) is an architectural programming pattern. He divides the user interface of the application ( referring to Ext JS - approx. Transl. ) Into three separate parts, helping to organize the code according to logical representations depending on their functions.



MVC implementations may vary from application to application, but basically, each part is responsible for its own:

• Model (model) - describes the used data format used in the application. It may contain business rules, validation rules and some other functions.
• View (view) - displays data to the user. Different views can display the same data in different ways (for example, tables and graphs).
• Controller (controller) - the central part of the MVC application. It monitors events inside the application and distributes commands between the model and the view.

MVC example

Let's look at an example in Sencha Fiddle:



In this example, we see a simple MVC application that includes the Master / Detail scheme. The main (master) view (Ext.grid.Panel) contains records that, when selected, fill in the associated subordinate (detail) view (Ext.form.Panel). Clicking the Save button (in the subordinate view) updates the entry in the main one.

Despite a simple example, it can be noted that there is quite a lot of manual work in the controller to bind the model and the view, especially for the subordinate view.

We will return to this example a little later, but for now let's look at alternative architecture.

What is MVVM?

Model-View-ViewModel ( MVVM ) is another architectural MVC-based programming template. The key difference between the two is that MVVM adds a View-ViewModel abstraction that tracks changes in model data and displays them in a view (data-binding) - something that is expensive to do in traditional MVC applications.



The MVVM template attempts to leverage the architectural advantages of MVC (division of responsibility), while providing additional convenience for date-binding. As a result, the model and the framework take over the work, thereby minimizing (and sometimes eliminating at all) the logic of the application that directly controls the presentation.

The elements of the MVVM template include:

• Model - describes the data format used in the application. Also, as in MVC.
• View - displays data to the user. Also, as in MVC.
• ViewModel is a view abstraction connecting the View and the corresponding Model. In MVC, this would be in the responsibility of some controller, but in MVVM ViewModel is directly involved in data-binding for a specific View.

Keep in mind that not all View requires ViewModel, but if they are used, then ViewModel are created for each View, so several instances can work simultaneously.

MVVM example

Considering the previous example based on MVC, it is clear that MVVM can solve some of the problems that we had by doing data-binding manually between the model and the components. In the new example , built on Ext JS 5, we replaced the Detail controller with ViewModel to transfer the recording data between two views.

Now we are no longer obliged to click "Save", because thanks to bidirectional binding, these records are updated instantly everywhere. This saves a lot of manual work and radically simplifies working with data in large applications.

What happened to the controllers in MVVM?

Despite the Model-View-ViewModel name, controllers can still be used in the MVVM template, although someone might call it MVC + VM architecture. Leaving the abbreviations aside, the main idea here is that Ext JS 5 does not force you to choose between MVC and MVVM (see the mixed example here ).

Ext JS 4 introduced MVC controllers in a broad sense, and Ext JS 5 also supports this concept. However, Ext JS 5 also supports the new version called ViewController.

ViewController is similar in nature to ViewModel. Both are aimed at a specific View, significantly eliminating the overhead in the traditional MVC for managing objects and restoring application state.

ViewControllers are also similar to the traditional (global) MVC controllers from ExtJS 4 in the way they monitor events and perform logic in response to these events. However, the key difference between ViewControllers and conventional Controllers is that ViewControllers are created for each corresponding View, when Controllers are in one instance and globally follow the events of several View.



ViewControllers and ViewModels participate in the life cycle of the components, which means that for each View instance, unique ViewModel and ViewController instances are created. Also, when destroying the View, the ViewModel and ViewController are deleted.

On the one hand, this is good news, because An application can (in theory) save memory and processing time, bypassing more general controllers that listen to the events of views globally, while the latter may not exist. On the other hand, the memory can vice versa due to the fact that several instances of ViewModels and ViewControllers work simultaneously.

The last thing to keep in mind is that not all View in MVVM require a ViewController: they are completely optional.

Conclusion

Ext JS 4 paved the way for corporate web applications to use MVC, which gave a stable code organization architecture. Ext JS 5 adds support for MVVM, while maintaining compatibility with MVC, so developers should not have problems upgrading their applications from Ext JS 4 to the latest version.

The best practices surrounding MVC are still relevant in Ext JS 5, while now using bi-directional data-binding, developers can significantly reduce the amount of code needed to build large and complex applications.

This is the first article in a series of reviews of the ideas of application architecture, MVVM, and date-binding. Stay tuned for upcoming detailed posts about ViewControllers and declarative listeners.

UPD. dew1983 Video from the webinar on this topic: vimeo.com/sencha/review/96094423/0255aad109