Angular的MVC理解--节自Adam Free的Pro angularv2

1. 定义

Angular的核心是采用MVC模式，即Model-View-Controller,也即MVW,Model-View-Whatever.

如下图所示，借助于ASP.NET的MVC模式来描述这三者关系：

Model：负责管理数据，有领域数据和视图数据，维护数据的管理逻辑和存储；

View：负责数据展示，如页面展示布局和页面数据，显示样式等；

Controller：是数据和视图的转换体；负责接收请求，然后进行数据的业务逻辑处理，和生产页面展示逻辑返回给View；

对应于Angular里面的叫法，如下图所示：

其中：

Model <---------> Model

View  <----------> Template

Controller <--------->Component

各模块的主要功能同MVC一致；

2. 理解Model

Model包括两部分数据，一部分叫View Model,仅仅指从Component里传递给Template的数据，用户能看到的展示数据（比如Template只看到的数组，字符串等）；该部分数据是为方便component于template的交互而使用；

另一部分即，领域数据，纯粹的跟应用所解决的商业领域相关的数据；包括对这些数据的创建，处理，存储，转换等维护逻辑；

注意：模型即数据，同时也包括对这部分数据的创建和管理逻辑；

对MVC模型来说，模型应该包括和不应该包括如下几点：

应该包括：

• 领域数据；
• 创建、管理和修改这些领域数据的业务逻辑（即使这会意味着需要通过web service执行远程逻辑)
• 提供干净的API接口，给用户获取数据和操作接口；

不应该包括：

• 暴露数据的获取和管理的细节（即数据的存储机制或者远程web service调用不应该暴露给controllers和views)
• 基于用户交互的变换模型数据的业务逻辑（这是component即controllers的职责)
• 将模型数据展示给用户（这是views的职责)

将模型和视图和控制器独立开来的好处是，模型可以独自进行单元测试，使得应用更简单和维护方便。最好的模型应该包括对该部分数据的业务操作逻辑，像CRUD和CQRS操作；

对前端的模型来说，模型中包含的数据的处理逻辑更多的知识通过Restful webservice触发后端（服务端）的数据库操作；比如SportsStore例子中的repository模型，里面就有很多ajax访问服务端的逻辑；

3.理解Component/controller

Controller即Angular里的Component，是Template和Model的连接纽带；它包括一些对数据的业务逻辑处理（注意是业务逻辑，不是创建、存储等CRUD逻辑）并负责将这部分数据发送给View；

它应包括：

• 建立template初始状态的逻辑
• 包括template展示model数据给用户的逻辑或行为
• 包括基于用户交互而带来的对模型数据更新的逻辑或行为

不包括：

• 操作DOM的逻辑（这是template的职责）
• 模型数据的持久化的逻辑（这是model的逻辑）

4. 理解Views/Templates

Views即Angular中的templates，它通过数据绑定来定影Html的元素和展示需要；数据绑定技术使得Angular非常灵活，它能转换Html元素，得以成为动态网页应用的基础。

Template应该包括：

• 将数据展示给用户端的标记和逻辑

不应该包括：

• 复杂的逻辑（那最好放在component中，或者angular的其他建造块中，像directives，services或者pipes）
• 对领域数据的CRUD操作（这是Model的职责）

5.MVC设计中的常见陷阱和原则

主要的陷阱是把对数据的逻辑处理放错了位置，下面是常见的三个放错位置的情况：

• 把业务逻辑放在Templates，而不是Components；
• 把领域逻辑放在Components，而不是Models；
• 当应用RESTful service时，把数据存储逻辑放在客户端的Model，而不是服务端的Model里。

逻辑处理的位置放置需要一定的开发经验，一般的原则如下：

• Template的逻辑一般是仅仅为展示而准备数据，并且从不修改数据；
• Component逻辑从不直接创建，更形或删除领域Model的数据；
• Templates和Components应该从不直接访问数据存储(如数据库访问)；