When the MVC design pattern was introduced for the first time in Ext JS 4, it completely revolutionized the Ext JS framework. Although MVC was well known as a design pattern, this was the first time a sophisticated JavaScript framework had implemented the strategy. There are several key benefits as follows:
- The MVC design pattern organizes code into logical realms or component types, which makes the code easier to understand
- MVC modularity can simplify component testing and refactoring as each object has a well-defined purpose
- The MVC design pattern architecture encourages cleaner code, clearly separating data access, presentation, and business logic
These were a huge advantage over the previous Ext JS 3 where the only true MVC component was the V (View). It was left to the Ext JS 3 developer to architect the M (Model) and C (Controller) as best they could, which often led to confusing and inconsistent code. Let's now look at how Ext JS 4 defines the MVC design pattern.
An Ext JS 4 model is a collection of properties that represent a domain entity. It may not come as a surprise that our 3T application will require a Company, Project, Task, User, and TaskLog model definition, just like they are represented in our Java domain layer. The main difference with our Java domain objects is that the Ext JS 4 model equivalent will be persistence aware. Thanks to the Ext JS 4 data package, each model instance will know how to persist and manage its state.
The Ext JS 4 view represents a logical visual component block and may itself include panels, toolbars, grids, forms, trees, and charts. An Ext JS 4 view always resides in its own file and should be as dumb as possible. This means that there should be no JavaScript business logic in the view; its purpose is to present data and provide interactive ability for the user.
The Ext JS 4 controller can be loosely described as the glue that binds together your application logic. Controllers are central in handling event processing and cross-view interactions and define the application workflows. The vast majority of JavaScript business logic code will reside in controllers.
Although we have a clear definition of the different MVC components, there is considerable implementation flexibility in the Ext JS 4 framework itself. We do not need to use controllers or models; in fact, we could easily build a fully working Ext JS 4 application using the same strategies followed in Ext JS 3. This would be a mistake, however, and should be avoided at all costs. The benefits of leveraging the MVC architecture for enterprise application development are significant, including, but not limited to, a simpler and more robust code base.