第110篇
极客时间《许式伟的架构课》课程笔记。
MVC架构
MVC
- MVC 全称是 “模型 (Model)- 视图 (View)- 控制器 (Controller)”
- Model 是 Input，View 是 Output，Controller 是 Process，认为 MVC 与计算机的 Input-Process-Ouput 这个基础模型暗合
- Model 是数据，View 是数据的显示结果，同时也接受用户的交互动作，也就是事件
- 若是由 Controller 负责监听并 Update View，就变成了 MVP 架构。MVP 全称是 “模型 (Model)- 视图 (View)- 表现 (Presenter)”
MVP
架构优劣评判标准
- 最低耦合原则：不同子系统（或模块）之间有最少的交互频率，最简洁且自然的接口
- 单一职责原则：不要让一个子系统（或模块）干多件事情，也不要让它不干事情
理解Model层
- Model 层是承载业务逻辑的 DOM，即 “文档对象模型（Document Object Model）”
- DOM 是 “面向对象” 意义上的数据。它不只是有数据结构，也有访问接口
- 架构误区：直接让Controller层直接操作数据库；用ORM技术实现Model层，直接让Controller操作ORM
- Model 层的使用接口最重要的是要自然体现业务的需求，职责应该是 “负责业务需求的内核逻辑”，以前经常叫它 “DataCore”
- Model 层负责发出 DataChanged 事件，它就是 Model 层面对需求变化点的对策，大部分 Model 层的接口会自然体现业务需求，这是核心价值点，是稳定的
理解View层
- View层首要责任是负责界面呈现，要么直接调用GDI接口自己画，要么创建子View让别人画
- View层的第二责任是响应用户交互事件的入口，理想情况下View应该把自己所有的事件都委托出去
- View 层不一定会负责生成所有用户看到的 View，有的View 是 Controller 的一部分
- View 层可能需要非常友好的委托（delegate）机制的支持
- View 层和 Model 层的关系非常紧密，紧密到需要知道数据结构的细节，这可能会导致 Model 层要为 View 层提供一些专享的只读访问接口
- View层负责界面呈现，不仅仅是根据数据绘制界面，在大部分情况下，只要业务稍微复杂一点，还会遇到性能挑战
理解Control层
- Controller 层负责用户交互。可以有很多个 Controller，分别负责不同的用户交互需求
- Model 层和View 层都是一个整体。Model层的很多类构成一个完整的逻辑：DOM。View层是 DOM 的界面呈现，是 DOM 的镜像，同样是一个整体
- 一个 Controller 模块，可能包含一些属于自己的辅助 View，也会接受 View 层委托的一些事件
- Controller 层最应该思考的问题是代码的内聚性
- 从分层角度来看，Model 层在最底层；View 层在中间，它持有 Model 层的 DOM 指针；Controller 层在最上方，它知道 Model 和 View 层，通过 DOM 接口操作 Model 层
- 应用程序负责把MVC各模块串起来，在应用开始的时候就把相关 Model 层、View 层，若干 Controller 模块都创建好并建立彼此的关联
