What is the benefit of using multiple modules in a

问题:

I'm a familiar person with Angular Js, recently I've seen that in some projects multiple angular modules are created and assembled in main module.

The code looks like.

angular.module("main",['main.sub1','main.sub2','main.sub2'])

angular.module("main.sub1",[])

angular.module("main.sub2",[])

angular.module("main.sub3",[])

My questions are

1. When to approach such fashion of splitting modules ?
2. How it is useful ?
3. Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider for each separately)
4. If i inject a dependency in sub modules are they by default injected in main modules ?

I read few blogs but I'm not able to get a clear perception.

Can you please guide me through.

回答1:

1.When to approach such fashion of splitting modules ?

Preferably, Always. But you don't really need to do it unless you have multiple apps that are using the exact same code, maybe the way you handle authentication in a few apps is identical, it would make sense to put the common code into a service and have that service as its own module. This offers code reuse, and we all know that code reuse is good.

2.How it is useful ?

Again, reusability is the key word here. You don't want to go around writing duplicate code. Code duplication is just plain wrong, and results in more expensive maintenance and more error prone code. Another advantage is that modularising your applications explicitly outlines the dependencies of your application and separates the responsibilities of different parts of your app. Code reuse and separation of concerns are fundamental practices in writing maintainable code.

Another reason to separate your app into modules is performance. Right now I'm working on an app (web shop) which consists of 2 main sections: one section(app) for normal users/buyers/sellers, and another app for the admin. Now the users app needs some scripts/libraries the admin app doesn't, and vice versa. For example the admin app uses a kendo grid which requires a kendo.all.min.js script which when minified is 1.7MB! Now would it make sense to force all visitors to the site to download the heavy 1.7 MB script?

3.Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider for each separately)

Yes. Ideally your applications will have different route/state configurations, so each app would have their own app.config(), this means you could define separate routes for each app using the shared modules. To my experience the main things you want to move into their own modules are services and directives, not applications routings.

4.If i inject a dependency in sub modules are they by default injected in main modules ?

Yes. If you inject a dependency X into a module A, and module A will be used by another module B then B will also inherit the dependency X.

回答2:

A module is the kernel of functionality for Angular apps. Modules contain all of the code that we write for our specific app and, thus, tend to grow huge in a monolithic way. Although this tendency isn’t bad (modules are a great way to reduce global scope noise), we can divide our modules.

There are several differing opinions about when to create a module and when to nest functionality in a global module. Both of the following methods are valid ways to break up our functionality by modules:

1. When to approach such fashion of splitting modules ?

When you want to sepereate your app logic by functionality or by routes, is needed because as your code separated on modules, it easy to understand, to tests and etc. angular module system implementation of Module Pattern.

Modules are an integral piece of any robust application's architecture and typically help in keeping the units of code for a project both cleanly separated and organized.

2.How it is useful ?

For starters, it's a lot cleaner for developers coming from an object-oriented background than the idea of true encapsulation, at least from a JavaScript perspective.

• Your significant other is the new developer on the team who's been asked to fix a bug on one of the many screens in your app.

  • The developer sifts through the directory structure and sees all the controllers, models and services neatly organized. Unfortunately it tells him/her nothing about which objects are related or have dependencies on one another.

  • If at some point the developer wants to reuse some of the code, they need to collect files from a bunch of different folders and will invariably forget code from another folder somewhere else.

3.Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider for each separately)

Another method we can use to break up our app is to divide our modules by route. This breakdown allows us to write isolated tests that focus on the functionality per route. Modularizing by route can make more sense, depending upon the project; it allows us to divide our functionality efficiently when we’re dealing with a lot of independent routes. For instance:

angular.module('myApp.home', []);
angular.module('myApp.login', []);
angular.module('myApp.account', []);
angular.module('myApp', [
'myApp.home',
'myApp.login',
'myApp.account'
]);

This modularization makes sense specifically when we’re dealing with large numbers of routes and/or when we don’t have too much cross-over between routes

4.If i inject a dependency in sub modules are they by default injected in main modules ?

shortly: yes. :)