3.2　Angular整体结构概述

接触过前端界面开发的读者应该都用过或者听说jQuery了。Angular与jQuery大不相同：Angular是一个开发框架，而jQuery是一个工具库。工具库像瑞士军刀，使用者觉得合适的时候就找到它的某个部件用一下，但是它基本不会对使用者提出过多要求或者严格限制，比如瑞士军刀不会要求小刀和开瓶器一定需要一起配合使用；而开发框架则大不相同，它已经通过自有的部分组成了一个环环相扣的有机整体，严格约定了使用者在哪里可以自由组合，在哪里必须按部就班。只有遵照它的要求嵌入和组合，才能保证体系在拼装运行时能正常工作。因此庞大严谨的Angular相对于灵活的jQuery要难学一些，不把Angular开发应用的整体结构和各部分组件职能了解清楚，会觉得没处下手或是使用时如堕五里雾中，即使勉强完成应用，也在其中埋了一些坑等着后人来慢慢填。

因此本节将先从Angular的整体入手，向读者简单介绍这个重型框架的开发语言TypeScript和几大特性。图3.4是笔者简化过的典型Angular应用结构图，图中前端区域包括了本章将要介绍的大部分内容，除了代码模块和依赖注入这两个抽象概念和变形过滤器这个工具类组件。

3.2.1　Angular与TypeScript

Angular是用TypeScript构建的。TypeScript作为ES6的超集，直接使用JavsScript也是可以的，但是使用TypeScript最大的好处就是它的类型系统。类型检查有助于在编译期预防bug，更有助于清晰表达自己的意图。

3.2.2　Angular实现了M.V.VM模式

MVVM模式是Model-View-ViewMode模式的简称。由视图（View）、视图模型（ViewModel）、模型（Model）三部分组成，通过这三部分实现UI逻辑、呈现逻辑和状态控制、数据与业务逻辑的分离。图3.4中从下至上组成MVVM的3部分：

•　模型（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。它代表了对后端数据直接访问的权利，例如对数据库的访问（后面我们会看到，这是通过服务Service来代理完成的）。模型本身并不依赖于视图和视图-模型。

•　视图-模型（View-Model）在中间负责与模型和视图互动，将模型的最新状态发送到视图，由其利用HTML和CSS来渲染内容。

•　视图（View）是Angular解析后渲染和绑定后生成的HTML。

Angular使用MVVM模式获得了4大好处：

1．低耦合

视图可以独立于模型变化和修改，一个视图-模型可以绑定到不同的视图上。当视图变化的时候模型可以不变，当模型变化的时候视图也可以不变。

2．可重用性

可以把一些视图的逻辑放在视图-模型里面，让很多视图重用这段视图逻辑。

3．开发与设计工作可分离

开发人员可以专注于业务逻辑和数据的开发（视图-模型）。设计人员可以专注于界面（视图）的设计。

4．可测试性

可以依据测试归约构造视图-模型来对界面（视图）进行测试。

3.2.3　Angular实现了模块化

把系统分割成多模块（Modules）的目的是通过定义公共APIs、限制行为（功能）和数据（属性和变量）的可视化，从而实现问题领域分离（Separation of Concerns）。大部分的编程语言内置了对模块化的支持，作为一个完整的开发框架，Angular实现了自己的模块化系统。这个系统有以下重要特性：

•　组件寄生于模块中：在定义与使用本章后面介绍的控制器、指令、过滤器和服务组件时，必须指明其所属的模块系统（Angular自带的核心组件除外）。

•　使用依赖注入：尽管服务组件是普通的JavaScript对象或函数，但为了不污染整体命名空间，这些服务不是定义在全局空间上，而是需要声明了对其的依赖，才能在其他模块中使用它们。

3.2.4　Angular实现了声明式界面

使用Angular框架标准的Web页面最显著的特点是它们表面上都是多了一些特别的属性tag（如：ngFor、ngIf、ngClass等）的静态HTML文档，却能具有动态行为能力。

在Angular中，这类HTML文件被称为模板，而ng-app这类标记被称之为指令。模板通过指令指示Angular进行必要的操作。比如：ng-app指令就被用来通知Angular自动引导一个Angular应用。

当Angular启动应用时，它会通过一个编译器解析处理这个模板文件，生成的结果就是图3.1里的视图部分。

3.2.5　Angular实现了双向数据绑定

目前市面上大多数的前端框架或库在数据模型和视图之间实现的都是单向数据绑定，而双向数据绑定是Angular较有特色之处。

图3.5中左边的模型图显示了单向数据绑定的常用模式，即数据模型与HTML模板结合生成了一次性的视图，数据流是单向的。而图3.5中右边的模型图显示的视图与模型之间是有相互交互机制的，从而使视图与模型互相形成数据成为可能，所以称之为双向数据绑定。而这个交互机制就是通过图3.4中的视图模型来完成的。

那么为什么需要双向数据绑定呢？它的意义在于给开发人员带来便利性和减少了烦琐易错的手工编写两层之间数据同步的工作量：

•　用户通过视图里的控件调整了语言配置、调整了夜间模式、输入了数据项，这些行为可以用几乎自动的方式来更新到数据模型。

•　当数据模型变化了，比如地理位置变化了、网络情况变化了、同步／异步推送的数据流变化了（比如实时聊天类应用）、被其他视图的输入改变了，所有视图都能几乎自动地持续反应数据模型的变化。

请注意上面两段话里都出现的几乎自动这四个字，它使设计人员和开发人员的任务分离成为可能。也正因为有这个便利性为Angular带来的成功，使后续出现的Vue.js、ReactJS等前端框架，在是否支持以及如何支持双向数据绑定上都面临一个艰难的决定（实现双向数据绑定也会带来一系列副作用，这就不属于本书讨论的范围了）。