共计 1219 个字符，预计需要花费 4 分钟才能阅读完成。
有一位 Angular 开发者提出了这样一个问题：
咱们有一个中型 Angular 应用程序，大略蕴含了 150 个 Component.
其中许多组件须要注入服务类并须要在应用程序中申明其余组件。
咱们始终在尝试并寻找对开发人员更敌对的一种办法。
目前的做法是，为每个组件创立一个模块。模块导入子组件模块并提供（或导入）组件所需的所有服务。它还导出组件自身，以便其余组件能够通过模块援用它。
它使组件的组合变得轻而易举，并且组件的测试 fixture 的设置非常简单（这是以前反复依赖项和子组件树依赖项的中央）。
这种办法仿佛与基于组件的架构相匹配，并容许围绕组件依赖项进行封装。
一个问题是，领有这么多模块 (module) 对性能（或其余）有什么影响？
答复
如果一个 module 依赖于其余组件，则能够只蕴含与每个间接依赖的组件相干的组件模块，而不须要关怀间接依赖。
这种办法起初可能看起来须要更多的开发量，但从久远上来看，它会带来更少的保护问题。
思考这样一个场景：
- Component A 依赖于 B，B 依赖于 C
- 那么首先创立 ModuleC，申明 Component C
- Module B 申明 Component B，同时导入 module C
- ModuleA 申明 Component A，同时导入 ModuleB. Module A 不须要间接导入 Module C.
如果因为我的项目起因，当初 Component B 须要依赖 Component D，比方在 HTML template 里应用如下语句：
<my-component-d>于是咱们只须要批改 Module B 即可，所有依赖于 Component B 的 Component 都能够持续失常工作。
Angular 里依赖治理的一个典型例子：
<script src="build/bundle.js"></script>或者将 vendor.js 和 main.js 离开：
<script src="build/vendor.js"></script>
<script src="build/main.js"></script>这样依赖关系能够通过形如 webpack 这种 module bundle 主动治理。
There is the approach of making a module with lots of components and just import it, but you end up importing several components that you don’t use and if you use lazy loading, your modules may become huge, unless you import that module in AppModule, making your boot time increase.
在 Feature Module 里 import Component Module:
feature.module.ts:
imports: [
ComponentAModule,
ComponentBModule,
ComponentCModule,
]