【前端MVC】如何理解angular的MVC模式

理解MVC模式

 近年来，MVC模式也被视为一种方式，来管理日益丰富而复杂的客户端Web开发，Angular就是在这种环境中诞生的。
 应用MVC模式的关键是实现关注点分离的关键前提，即应用程序中的数据模型与业务模型和表现逻辑分离。在客户端Web开发中，这意味着分离数据、操作该数据的逻辑以及用于显示数据的HTML元素。结果是客户端应用程序更容易开发、维护和测试。
 三个主要构建模块是模型、控制器和视图。下图显示了MVC模式在应用于服务器端开发时的传统阐述。模型一般是从数据库中获得的，而应用程序的目标是为来自浏览器的HTTP请求提供服务。

  Angular存在于浏览器中，这造成MVC的变化，区别于服务器端的实现，如下图：

 MVC模式的客户端实现通常是通过Restful Web服务，从服务器端组件中获取数据。控制器和视图的目标是对模型中的数据进行操作，以执行DOM操作，从而创建和管理用户可以与之交互的HTML元素。这些交互操作会反馈给控制器，闭环循环，以形成交互式应用程序。
  Angular对其构建使用的术语略有不同，这意味着使用Angular实现的MVC模型如下图所示：

理解模型

 模型包含用户使用的数据。模型有两大类型：视图模型和域模型，视图模型只表示从组件传递到模板的数据；域模型包含业务领域的数据，还包括操作、存储和处理这些数据的规则，统称为模型逻辑。
在使用MVC模式构建的应用程序中，模型应该：

• 包含域数据，
• 包含用于创建、管理和修改域数据的逻辑，
• 提供一个干净的API，用于公开模型数据和模型上的操作

 模型不应该：

• 公开如何获取或管理模型数据的细节，
• 包含基于用户交互操作转换模型的逻辑（因为这是组件的工作），
• 包含向用户显示数据的逻辑（这是模板的工作）

 确保模型与控制器和视图隔离的好处是，可以更容易地测试逻辑，增强和维护整个应用程序也更加简单、容易。
 最好的域模型包含用于获取和持久存储数据的逻辑，以及用于创建、读取、更新和删除操作（CURD）逻辑，或者用于查询和修改数据的单独模型，称为命令和查询责任隔离。
这可能意味着模型直接包含逻辑，但更常见的情况是，模型包含的逻辑会调用Restful Web服务，以调用服务器端的数据库操作。

理解控制器/组件

 控制器是Angular Web应用程序中的结缔组织，充当数据模型和视图之间的管道。组件添加了表示模型的某些方面，并对其执行操作所需的业务域逻辑。遵循MVC模式的组件应该：

• 包含设置模板初始化状态所需的逻辑，
• 包含模板所需的逻辑/行为，以显示模型中的数据，
• 包含基于用户交互操作更新模型所需的逻辑/行为

 组件不应该：

• 包含操作DOM的逻辑（这是模板的工作），
• 包含管理数据持久化的逻辑（这是模型的工作）

理解视图数据

 域模型并不是Angular应用程序中的唯一数据。组件可以创建视图数据（也称为视图模型数据或视图模型），来简化模板及其组件的交互。

理解视图/模板

 视图（Angular中称为模板）是使用通过数据绑定增强的HTML元素定义的。正是数据绑定使Angular如此灵活，它们将HTML元素转换为动态Web应用程序的基础。模板应该：

• 包含向用户显示数据所需的逻辑和标记

 模板不应该：

• 包含复杂的逻辑（最好放在组件或其他Angular构建块中，如指令、服务或管道），
• 包含创建、存储或操作域模型的逻辑

 模板可以包含逻辑，但它应该是很简单的，应节约使用。

设计缺陷–将逻辑放错地方

 最常见的问题是将逻辑放入错误的组件中，从而破坏MVC关注分离点。以下是这个问题最常见的三种类型：

• 将业务逻辑放在模板中，而不是组件中
• 将域逻辑放在组件中，而不是模型中
• 在使用Restful服务时，将数据存储逻辑放入客户端模型

 这些都是棘手的问题，因为它们需要一段时间才能表现为问题。应用程序仍然在运行，但是随着时间的推移，它将变得更难增强和维护。
 在Angular开发中获得更多经验后，确定把逻辑放在哪里应该成为第二天性，这3条规则值得遵守：

• 模板逻辑应该只准备用于显示的数据，而不应该修改模型
• 组件逻辑不应该直接从模型中创建、更新或删除数据
• 模板和组件永远不能直接访问数据存储

 如果在开发过程中记住这些，就可以避免最常见的问题。