The clothes stacked on the floor
First, let's take a look at Angular-seed, an official entry project for ANGULARJS application development, whose file structure is this:
css/
img/
js/
App.js
Controllers.js
Directives.js
Filters.js
Services.js
lib/
partials/
It looks like a pile of clothes on the floor, a pile of socks, a pile of underwear, a bunch of shirts, and so on. You know the socks on the corner have black wool socks to wear today, but you still need to spend some time looking for them.
This is a messy organization. Once you have 6, 7, or more controllers or services in your code, file management becomes unmanageable: it's hard to find the objects you're looking for, and the changes to the files in source control become difficult to understand.
Sock drawer
The common JavaScript file structure has another form of classifying files by prototype. We continue to use the clothes to compare: now we buy a wardrobe with many drawers, we intend to put socks in one of the drawers, underwear in another drawer, and then neatly folded shirts in the third drawer ...
Imagine that we are developing a simple E-commerce site that includes the landing process, the product catalog, and the shopping cart UI. Similarly, we divide the files into the following prototypes: Models (business logic and status), controllers, and services (Http/json endpoint encryption), which are loosely grouped into the service architecture, as angular default. So our JavaScript directory becomes this:
controllers/
Logincontroller.js
Registrationcontroller.js
Productdetailcontroller.js
Searchresultscontroller.js
Directives.js
Filters.js
models/
Cartmodel.js
Productmodel.js
Searchresultsmodel.js
Usermodel.js
services/
Cartservice.js
Userservice.js
Productservice.js
Yes, it is now easier to find files through the tree file directory or IDE shortcuts, and the Change set (changeset) in source control can clearly describe file modification records. Although a great improvement has been achieved, there are still some limitations.
Imagine you're in the office right now, and suddenly you find a business trip tomorrow and you need a couple of dry cleaning clothes, so call your family and tell the other half to give the cleaners a black and blue suit and a black tie with a gray shirt and a white shirt with a pure yellow tie. If your partner isn't familiar with the wardrobe, how do you pick out the right needs from three yellow ties?
of modular
I hope the analogy of clothes doesn't make you feel too old, here's an example:
Your partner is a new developer who is being asked to fix a bug in this complex application.
He swept through these folders and saw the folders of controllers, models, and services neatly lined up, but he still didn't know the dependencies between objects.
For some reason, he wanted to be able to reuse part of the code, which required collecting files from various folders and often omitting objects from certain folders.
Believe it or not, you rarely reuse a lot of code in a new project, but you probably need to reuse an entire module like the login system. So is it better to divide files by function? The following file structure is a functional partition of the application structure:
cart/
Cartmodel.js
Cartservice.js
common/
Directives.js
Filters.js
product/
search/
Searchresultscontroller.js
Searchresultsmodel.js
Productdetailcontroller.js
Productmodel.js
Productservice.js
user/
Logincontroller.js
Registrationcontroller.js
Usermodel.js
Userservice.js
Although there are space restrictions in the real world, it is difficult to organize clothes at will, but similar processing in programming is 0 cost.
Now even the new developer can understand the function of the application by naming the top-level folder, the files under the same folder will be dependent on each other, and the principle of login, registration and so on can be easily understood simply by browsing the file organization structure. New projects can also reuse the code by copying and pasting.
Using ANGULARJS we can further organize the relevant code into modules:
1
2
3
4
5
6
7
8
9
10
11
12
13 |
var usermodule = angular.module (' Usermodule ', []);
Usermodule.factory (' UserService ', [' $http ', function ($http) {
return new UserService ($http);
}]);
Usermodule.factory (' Usermodel ', [' UserService ', function (UserService) {
return new Usermodel (UserService);
}]);
Usermodule.controller (' Logincontroller ', [' $scope ', ' Usermodel ', Logincontroller]);
Usermodule.controller (' Registrationcontroller ', [' $scope ', ' Usermodel ', Registrationcontroller]); |
If we put the Usermodule.js file in the user folder, it becomes the "manifest" of the object used in this module, which is also suitable for placing certain loading instructions Requirejs or browserify.
How to work with common code
Each application has some code that is widely used in multiple modules, and we often use folders called "Commom" or "shared" to store these feature codes. And how do you deal with these common code?
If an object in a module needs to access several "generic" objects directly, provide several facades (skin patterns) for those objects. This helps reduce the dependencies on each object, and too many associated objects often mean bad code structures.
If the "generic" module becomes too large, you need to subdivide it into multiple sub modules by functional area. Make sure that each application module uses only the "generic" modules it needs, which is a variant of the "interface isolation principle" in solid.
Adding entities to the root range ($rootScope) can also be used in such a way that it is appropriate for multiple controllers to rely on the same object (such as "Permissionsmodel").
Use events when you decouple two components that are not explicitly referenced to each other. The $emit, $broadcast, and $on methods of the scope object in angular make this approach realistic. The controller can trigger an event to perform certain actions, and then receive a corresponding notification when the action ends.
This article links http://www.cxybl.com/html/wyzz/JavaScript_Ajax/20130902/40019.html
