JavaScript MV* 模式
在JavaScript中最重要的三个MV* 模式:MVC、MVP以及MVVM。
MVC
MVC 是一种架构设计模式,通过关注点分离鼓励改进应用程序组织。强制将业务数据(Model)与用户界面(View)隔离,第三个组件(Controller)仍然管理逻辑和用户输入
JavaScript中支持MVC的框架:Backbone、Ember.js和Angular
MVC核心
1. Model(模型)
管理应用程序的数据。不涉及用户界面及表示层,代表应用程序可能需要的独特形式的数据。当Model改变时,通常会通知它的观察者(eg:View)
Model主要是与业务数据有关
2. View(视图)
是Model的可视化表示,表示当前状态的筛选视图。
一个View通常检测一个Model,并在Model更改时进行通知,使View本身能够相应的更新。
View是应用程序数据的可视化表示
3. Controller(控制器)
Controller是Model和View之间的中介,当用户操作View时,它通常负责更新Model。
Controller在MVC中扮演一个角色:View策略模式的简易化。在策略模式方面,View在其判断力下将委托给Controller进行操作。当View认为合适时,View可以委托Controller来处理用户事件,也可以委托Controller处理Model更改事件。
Controller管理应用程序中Model和View之间的逻辑和协调
MVC为我们提供了什么
1. 整体维护更容易。数据中心是否改变,什么时候需要更新应用程序这点很清楚,这意味着是Model或者Controller的变化,或者仅仅是View改变
2. 解耦Model和View,意味着它能够更直接地编写业务逻辑的单元测试
3. 在整个应用程序中,底层Model和Controller代码的重复被消除
4. 取决于应用程序的大小和角色的分离,这种模块性可以让负责核心逻辑的开发人员和负责用户界面的开发人员同时工作
MVP
是MVC的一种衍生模式,专注于改进表示逻辑MVP
核心(Model、View、Presenter)
MVP中的P代表表示层。这是一个包含于View的用户界面业务逻辑的组件。与MVC不同,来自View的调用将委托给表示层,表示器是从View中解耦,通过接口与它对话。
在MVP中,当Model变化时,监控Model和更新View。P将Model有效地绑定至View,是MVC中Controller的责任
MVP或MVC?
MVP最常用于企业级应用程序,这种应用程序需要尽可能多地重用表示逻辑。具有非常复杂的View和大量用户交互的应用程序可能发现MVC并不适用。在MVP中,所有复杂的逻辑可以封装在一个Presenter中,可简化维护工作。
由于MVP中的View是通过接口被定义的,从技术上讲,接口是系统和View之间唯一的接触点。
根据不同的实现,使用MVP进行单元测试可能比MVC更容易。由于Presenter可以被当作一个完整的用户界面模拟,因此可以独立于其他组件而进行测试。
MVVM
是一种基于MVC和MVC的架构模式,视图更清晰地讲用户界面开发从应用程序的业务逻辑与行为中分离。MVVM
核心
1. Model
表示应用程序将会使用的特定领域的数据或信息。保存信息,但通常不处理行为,不会格式化信息或影响数据在浏览器中显示的方式。
数据格式化由View来处理的,而行为被认为是业务逻辑,应该封装在与Model交互的另一层:ViewModel
2. View
仅是与用户进行交互的应用程序的一部分。是一个交互式UI,描绘ViewModel的状态。从这个意义上说,View被认为是主动而不是被动。被动View只输出显示,并不接收任何用户输入,没有真正的Model,并且可以被表示器控制。
MVVM的主动View包含数据绑定、事件和行为。
View并不负责处理状态;它仅仅是让状态与ViewModel保持同步
3. ViewModel
可作为一个专门的Controller,充当数据转换器。将Model信息转变为View信息,还将命令从View传递到Model
ViewModel位于UI层的后面。暴露了View所需的数据,可以被视为View数据和操作的源头
4. View和ViewModel
View和ViewModel之间通过数据绑定和事件进行通信。ViewModel不只暴露Model属性,还会访问其他方法和验证类的特性。
View处理自己的用户界面事件,必要时将它们映射到ViewModel。Model和ViewModel上的属性通过双向数据绑定进行同步和更新
5. ViewModel和Model
ViewModel似乎可以完全负责MVVM中的Model,可以为了数据绑定而暴露Model或Model属性,也可以包含接口,用于获取和操作在View中暴露的属性
优点
1. 使得UI和为UI提供驱动的行为模块的并行开发更容易
2. 使View抽象化,从而减少代码背后所需的业务逻辑
3. ViewModel中单元测试中的使用比在事件驱动代码中的使用更加容易
4. 不需要考虑UI自动化和交互就可以测试ViewModel
缺点
1. 对于简单UI来说,MVVM有些大材小用
2. 数据绑定可以使声明性的,使用方便,但比命令式代码难调试,在命令式代码中,只需设置断点
3. 大型应用程序中的数据绑定可以产生大量的标记。绑定比被绑定的对象还要繁多
4. 在较大型应用程序中,预先设计大量的ViewMode可能更加困难
MVC、MVP和MVVM
MVP和MVVM均是MVC的衍生品。
在MVC中,View位于架构之上,与Controller相邻。Model位于Controller之下,因此View了解Controller,Controller了解Model
在MVP中,Controller被Presenter所替代。Presenter与View位于同一位置,监听View和Model事件,并调解它们之间的行动
MVVM允许我们创建Model特定于View的子集,可以包含状态和逻辑信息,无需向View暴露整个Model。与MVP的Presenter不同,引用View时不需要ViewModel。View可以绑定到ViewModel上的属性,而属性会将Model所包含的数据暴露给View。
MVVM中ViewModel和View之间需要进行解释,会带来性能成本