刚接触Angular的时候觉得它的模块化让人非常不适应，并且使用TypeScript编写后更是提升了一些学习曲线，在感觉高大上的同时一头雾水摸不清。仔细学习和研究了之后发现要使用好Angular，对应用的架构要求具有高度组织性和层次性，但初学者非常容易在逻辑和文件层面出现组织混乱。为了理清这种混淆，首先得明确NgModule的概念。
NgModule
Angular赖以实现模块化开发和构建应用的方式就是定义了自身框架的模块化系统NgModule。对模块化如此强调的原因有开发者意识层面的原因，也有实践层面的原因，在Angular中尤其关键，逻辑层面的功能组织都是围绕模块来展开的。NgModule的含义有广狭之分，广义的概念就是指代Angular框架中的模块体系，狭义的概念是Angular框架中最基础的构建单元，即Angular应用是由一个个NgModule组成的，它具有代码实体。
作用
NgModule最主要的用途就是在逻辑层面上组织代码，它也体现在文件组织上。
-
模块化：将实现一个具体功能集或特性的各部分归集到一个模块中，达到逻辑上的模块化，可以通过对这个模块进行导入和删除而引用和移除这个模块的功能。模块可以包含多个组件和服务。这个模块具体做了以下事情：
- 引入其他模块导出的内容
- 声明模块包含的各部分内容
- 为模块内各部分提供统一的编译上下文
- 导出本模块可供其他模块依赖的内容
-
代码组织：除了在逻辑层面上进行组织，文件目录中也能体现这种模块化的代码组织方式，一个模块可以体现为一个目录，通过添加和移除目录来实现这部分代码的引入和删除，做整体化的模块增减。文件夹中包含了模块文件、入口组件和路由文件，然后再通过子层的组件文件夹去实现具体的视图或其他功能。一个文件组织非常到位的实例是ngx-admin，具体的文件组件方式也要根据应用的复杂程度来调整。另外官方已经推荐了比较好的实践范式，这篇文章中最后整理出的体系图可以为开发者提供一个最佳实践的示意图。
内容
-
组件：组件与Vue中的组件含义略有差异。在Angular中，组件的作用被要求更加单纯，主要是模板和数据视图的中间层，定义与视图有关的逻辑，它通过文件夹的方式组织起来，组成的构建块分别有html模板、css文件和ts视图逻辑文件。尽管不把服务等与视图无关的逻辑按文件拆分开来放也不影响最终的应用实现，但Angular希望能让组件与服务这些用装饰器实现的声明类在逻辑层面上各司其职，在文件组织层面上各就其位。根据构建单元的引用层级，组件一般还包含了以下部分：
- 模板：与组件关联的html文件
- 指令：Angular提供的结构化指令如
*ngIf、*ngFor，插值模板指令如ngModel，可自定义 - 管道：格式化显示插值
- 服务：与视图无关并可跨组件共享的功能模块。
NgModule与ES Module
ES Module是语言语法层面上的模块体系，NgModule是Angular逻辑框架层面上的模块体系，这两个模块系统的层面不同，是无冲突的。简而言之，ES Module的使用以文件为单位，在其他框架构建的应用中与NgModule毫无关联。
在Angular应用中，模块的实现依赖于这两个模块系统的结合，是相辅相成的。由于NgModule是框架自身以逻辑实现的，与文件的绑定并无严格关系，模块导入这种语法层面的事情还是得需要ES Module来处理，所以通过分析，可以很显然得出结论，ES module处理文件依赖关系，NgModule处理应用逻辑依赖关系。
装饰器
Angular架构中使用JS特性最突出的一点就是类，所有逻辑功能单元都被声明为类，模块、组件、服务、指令、管道等都是作为类来导出，而这些类本身是没有办法区分彼此，难道都只能通过口头约定么？
另一个特性装饰器无疑为这个问题提供了一个近乎完美的解决方案，装饰器这个概念的引入得益于其他高级语言，而且这个方案的应用早就很成熟了，Python里就屡见不鲜。之前在学习ES6特性的时候一直觉得此特性只可远观，通过学习Angular的一番实践，终于知道它是多么强大的开发助攻了。
在Angular所有的构建单元声明前都要包装一层装饰器，元数据作为一个对象传入装饰器中用来在内部逻辑中将类和声明的另一些构建块（如模板、样式）和构建单元建立关联，同时明确这个类的身份。这样在构建单元相互引用依赖时，就能区别引入的构建单元的类型，同时会制约它们的行为。
Angular应用的基础架构
装饰器是Angular架构中高层的抽象机制它区别了Angular中声明类的类别，NgModule是逻辑层面的组织结构，它与装饰器一起构筑了整个Angular应用架构的基石。
网友评论