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应该从不直接访问数据存储(如数据库访问)；