Design your application architecture in Ext JS 4
Scalability, ease of maintenance and application flexibility are largely determined by the quality of the application architecture. Unfortunately, the application architecture is often referred to as secondary factors. Concepts and prototypes are turned into mass applications, and code samples are copied and pasted “as is” into the foundation of many applications. You may want to move in an easy way because of the rapid progress that you see at the beginning of the project.
However, the time savings will be relatively low compared with the time spent on the need to maintain the application, ensuring its scalability, and often, on the late refactoring of the application. One of the ways to get better prepared for creating a serious architecture is to follow certain agreements and define the views, models, repositories and application controllers before they are implemented. In this article, we will look at a popular application and discuss how we could build a user interface to create a solid foundation.
')
The application architecture describes both the structure and sequence of code organization, as well as the actual classes and libraries used. Creating a good architecture offers a number of important advantages:
Although Ext JS 4 offers best practices on how to structure your application, it is possible to change the conventions we have proposed for naming files and classes. For example, you can decide that you need to add a suffix to the “Controller” controllers in the project, for example, “Users” become “UsersController”. In this case, do not forget to always add the suffix not only to the name of the class, but also to the name of the corresponding file. The important thing is that you must define these conventions before you start writing an application, and follow them consistently. Finally, although you can name your classes as you please, we strongly recommend that you follow our convention for folder names and structures (controllers, models, stores, views). This will ensure that you get optimized code using our SDK Tools beta .
Dividing the user interface of an application into views is a good starting point. Often, you get sketches and user interface layouts created by designers. Imagine that we are asked to recreate the (very attractive) Pandora application using Ext JS, and we are provided with the following layouts from our interface designer:
What we want to achieve is a balance between making the representations too detailed or too general. Let's imagine what happens if we split our interface into too many views:
Splitting the interface into too many small views makes it very difficult to use, monitor, and manage views in our controllers. In addition, since each view will be located in a separate file, creating too many views can make it difficult to find a view file that defines the part of the user interface or view logic that we need.
On the other hand, we do not want our ideas to be too general, as this will affect our flexibility — the ability to change things.
In this case, each of our submissions was oversimplified. When several parts of a view require specific logic, the view class becomes responsible for too much, which makes it difficult to maintain. In addition, when designers change their mind about the location of the interface, we ultimately have to reorganize our definition of presentation and its logic, which can become tedious.
The right balance is achieved when we can easily change the layout of the views on the page without having to refactor them every time. For example, we want the ad unit (Ad) to be a separate view so that we can easily move it, or even delete it later.
In this version, we split our user interface according to the roles of each view. If you have a general idea of ​​the views that form your user interface, you can still customize the details already at the implementation stage. Sometimes you may find that two presentations should actually become one, or the presentation is too general and should be divided into several representations, but the initial breakdown helps to start with a good foundation. I think we did it now.
Now that we have the basic structure of our ideas, it's time to look at the models. Looking at the types of dynamic data in our user interface, we can get information about the various models needed for our application.
We decided to use only two models - Track (Song) and Radio Station (Station). We could define two more models for the artist and the album. However, as with ideas, we do not want to be too detailed when defining our models. In this case, we should not separate the information about the artist and the album, because the application does not allow the user to select a particular song by the specified artist. Instead, the data is organized by radio stations. The track is the central figure, the performer and the album are properties of the track. This means that we can combine track, artist and album data in one model. This greatly simplifies working with data for our application. It also simplifies the APIs that we need to implement on the server side, because we don’t have to download individual artists or albums. Summing up for this example, we will have only two models, a music track and a radio station.
Now that we have thought about which models will be used by our application, it's time to think about storage.
Figuring out what you need in different repositories is often relatively easy. A good strategy is to identify all the components associated with the data on the page. In this case, we have a list with all the user's favorite radio stations, a scroller with the last tracks played and a search field that will display the search results. Each of these views must be associated with repositories.
There are several ways in which you can distribute application responsibilities to all application controllers. Let's think about which controllers we need in this example.
Here we have two main controllers - SongController and StationController. Ext JS 4 allows you to have a controller that can manage multiple views at the same time. Our StationController will process the logic for creating new stations as well as for loading the user's favorite radio stations into the StationsList view. SongController takes care of managing the SongInfo view, and RecentSong storage, as well as user actions like, dislike, stop, or skip a track. Controllers can communicate with each other by generating events and subscribing to application events. Although we could create additional controllers, one to control playback and the other to search for a station, I think we found a good division of responsibilities.
I hope that our thoughts about the importance of planning your application architecture before writing code turned out to be useful to someone. We believe that discussing the details of the application will help you build a much more flexible and convenient architecture.
Author: Tommy Mainz.
However, the time savings will be relatively low compared with the time spent on the need to maintain the application, ensuring its scalability, and often, on the late refactoring of the application. One of the ways to get better prepared for creating a serious architecture is to follow certain agreements and define the views, models, repositories and application controllers before they are implemented. In this article, we will look at a popular application and discuss how we could build a user interface to create a solid foundation.
Code organization
')
The application architecture describes both the structure and sequence of code organization, as well as the actual classes and libraries used. Creating a good architecture offers a number of important advantages:
- Each application is always written the same way, so you need to learn this structure only once;
- It is easy to share code between applications, since they all work the same way;
- You can use Ext JS build tools to create optimized versions of applications for industrial use.
Although Ext JS 4 offers best practices on how to structure your application, it is possible to change the conventions we have proposed for naming files and classes. For example, you can decide that you need to add a suffix to the “Controller” controllers in the project, for example, “Users” become “UsersController”. In this case, do not forget to always add the suffix not only to the name of the class, but also to the name of the corresponding file. The important thing is that you must define these conventions before you start writing an application, and follow them consistently. Finally, although you can name your classes as you please, we strongly recommend that you follow our convention for folder names and structures (controllers, models, stores, views). This will ensure that you get optimized code using our SDK Tools beta .
Achieving a balance
Dividing the user interface of an application into views is a good starting point. Often, you get sketches and user interface layouts created by designers. Imagine that we are asked to recreate the (very attractive) Pandora application using Ext JS, and we are provided with the following layouts from our interface designer:
What we want to achieve is a balance between making the representations too detailed or too general. Let's imagine what happens if we split our interface into too many views:
Splitting the interface into too many small views makes it very difficult to use, monitor, and manage views in our controllers. In addition, since each view will be located in a separate file, creating too many views can make it difficult to find a view file that defines the part of the user interface or view logic that we need.
On the other hand, we do not want our ideas to be too general, as this will affect our flexibility — the ability to change things.
In this case, each of our submissions was oversimplified. When several parts of a view require specific logic, the view class becomes responsible for too much, which makes it difficult to maintain. In addition, when designers change their mind about the location of the interface, we ultimately have to reorganize our definition of presentation and its logic, which can become tedious.
The right balance is achieved when we can easily change the layout of the views on the page without having to refactor them every time. For example, we want the ad unit (Ad) to be a separate view so that we can easily move it, or even delete it later.
In this version, we split our user interface according to the roles of each view. If you have a general idea of ​​the views that form your user interface, you can still customize the details already at the implementation stage. Sometimes you may find that two presentations should actually become one, or the presentation is too general and should be divided into several representations, but the initial breakdown helps to start with a good foundation. I think we did it now.
Models
Now that we have the basic structure of our ideas, it's time to look at the models. Looking at the types of dynamic data in our user interface, we can get information about the various models needed for our application.
We decided to use only two models - Track (Song) and Radio Station (Station). We could define two more models for the artist and the album. However, as with ideas, we do not want to be too detailed when defining our models. In this case, we should not separate the information about the artist and the album, because the application does not allow the user to select a particular song by the specified artist. Instead, the data is organized by radio stations. The track is the central figure, the performer and the album are properties of the track. This means that we can combine track, artist and album data in one model. This greatly simplifies working with data for our application. It also simplifies the APIs that we need to implement on the server side, because we don’t have to download individual artists or albums. Summing up for this example, we will have only two models, a music track and a radio station.
Storage
Now that we have thought about which models will be used by our application, it's time to think about storage.
Figuring out what you need in different repositories is often relatively easy. A good strategy is to identify all the components associated with the data on the page. In this case, we have a list with all the user's favorite radio stations, a scroller with the last tracks played and a search field that will display the search results. Each of these views must be associated with repositories.
Controllers
There are several ways in which you can distribute application responsibilities to all application controllers. Let's think about which controllers we need in this example.
Here we have two main controllers - SongController and StationController. Ext JS 4 allows you to have a controller that can manage multiple views at the same time. Our StationController will process the logic for creating new stations as well as for loading the user's favorite radio stations into the StationsList view. SongController takes care of managing the SongInfo view, and RecentSong storage, as well as user actions like, dislike, stop, or skip a track. Controllers can communicate with each other by generating events and subscribing to application events. Although we could create additional controllers, one to control playback and the other to search for a station, I think we found a good division of responsibilities.
Seven times measure cut once
I hope that our thoughts about the importance of planning your application architecture before writing code turned out to be useful to someone. We believe that discussing the details of the application will help you build a much more flexible and convenient architecture.
Author: Tommy Mainz.
Tommy Mainz is developing the Sencha Touch. With extensive knowledge of object-oriented JavaScript and knowledge of the individual characteristics of mobile browsers, he pushes the boundaries of what is possible within mobile browsers. Tommy brings a unique perspective and ambitious philosophy to create attractive user interfaces. His attention to detail leads to the realization of the desire to find the perfect framework for developers.
Follow Tommy on Twitter
Source: https://habr.com/ru/post/122993/
All Articles