mvc,mvp,mvvm简介

      MVC是一种架构设计模式，它通过关注点分离鼓励改进应用程序组织。它强制将业务数据(Model)与用户界面(View)隔离，第三个组件(Controller)仍然管理逻辑和用户输入。这种模式是Smalltalk-80的研究期间设计出来的，这其中有一些有趣的地方：

    Model 代表特定于领域的数据，不了解用户界面(View（视图）和Controller（控制器）)。当一个Model改变时，它会通知它的观察者。 

   View描绘的是Model的当前状态。Observer模式用于让View了解Model什么时候更新或修改

    Presentation由View关注，但不只是单个View（视图）和Controller（控制器），屏幕上显示的每个部分或者元素都需要View-Controller对。

    Controller在这个View-Controller对中的作用是处理用户交互（如按键和点击等动作），为View做决定。

 

 

1.Model

    Model管理应用程序的数据。Model不涉及用户界面，也不涉及表示层，而是代表应用程序可能需要的独特形式的数据。当Model改变时，它会通知它的观察者（如视图），就可以做出相应的反应。

    总的来说，Model主要是与业务数据有关。

2.View

     视图是Model的可视化表示，表示当前状态的筛选视图。Javascript的View是关于构建和维护一个DOM元素。

     一个View通常检测一个Model，并在Model更改时进行通知，使View本身能够相应的更新。View对应用程序中的Model和控制器的了解是有限的。

    用户可以与View交互，包括读取和编辑Model，在Model中获取或设置属性值。

    更新Model的实际任务是在Controller上。

    长期以来我们都是了解到手工创建大量的HTML标记并通过字符串拼接是非常不好的性能实践。开发者会遭受遍历非正常格式数据的折磨，在嵌套的div中对它进行包装，这是非常痛苦的。

    js模板解决方案（Handlerbars.js，Mustache，jsRender，artTemplate等）通常是用于将View模板定义为包含模板变量的标记（或者是存储于外部，或者是使用自定义类型的script标签，如text/template）。可以使用变量语法对变量进行定界（如{{name}}）,框架接受JSON形式的数据（Model模型实例可以被转换成这种形式），这样，就只需要关注保持整洁的Model和模板了。大部分数据绑定工作由框架自身完成，选择在外部存储模板时，因为构建更大的应用程序，它可以让路给按需动态加载的模板。

     注意，模板本身并非是View。View是一个用于检测Model并保持可视化表示更新的对象。模板可能是一种指定部分或甚至所有View对象的声明方式，这样它就可以从模板规范中生成了。

    总之View是应用程序数据的可视化表示。

3.Controller

    Controller是Model和View之间的中介，当用户操作View时，它通常负责更新Model.

   Conntrollr在MVC中扮演一个角色：View策略模式的简易化。在策略模式方面，View在其判断力下将委托托给Controller进行操作，这是策略模式的工作原理。

    在大多数jsMVC框架中,Controller的设计和真正的MVC中的概念还是不一样的。如Backbone，包含Model和View，但它实际上并没有真正的Controller。其View和路由的行为与Controller有点类似，但它们实际上都不是Controller.

    总体来说，Controller管理应用程序中Model（模型）和View(视图)之间的逻辑和协调

    MVC为我们提供了什么

 

     MVP（表示器）是MVC设计模式的一种衍生模式，专注于改进表示逻辑。

     与MVC不同，来自VIEW的调用将委托给表示器，表示器是从VIEW的解耦，通过接口与它对话。

    由View进行请求，表示器执行任何与用户请求有关的工作，并将数据回传给它们。

    MVC这种变化的好处是它能够提高应用程序的可测试性，并在VIEW和MODEL之间提供更清晰的分离。

 

    MVVM(模型-视图-视图模型)是一种基于MVC和MVP的架构模式，它试图更清晰地将用户界面（UI）开发从应用程序的业务逻辑与行为中分离。为此，很多这种模式的实现都要利用声明式数据绑定来实现将VIEW工作从其他层分离。

    这有助于在同一个代码库中UI和开发工作的同时进行。UI开发人员在其文档标记(html)内编写到ViewModel的绑定，其中的Model和ViewModel都是由研究应用程序逻辑的开发人员来进行维护。

    Model还是表示应用程序将会使用的特定领域数据或信息。

View

    与MVC一样，View实际上仅是与用户进行交互的应用程序的一部分。它们是一个交互式UI，描绘ViewModel的状态。从这个意义上说，View被认为是主动而不是被动的，对于MVC和MVP的View这也是正确的。在MVC、MVP、MVVM中，View也可以是被动的，这意味着什么？

    被动View只输出显示，并不接收任何用户输入。这种View在应用程序中，可能也没有真正的Model知识，并且可以被表示器控制。MVVM的主动View包含数据绑定、事件和行为，需要对ViewModel有了解。虽然这些行为可以被映射到属性，但View仍负责处理ViewModel的事件。

    重要牢记的是，View并不负责处理状态；它仅是让状态与ViewModel保持同步。

ViewModel

可以将ViewModel作为一个专门的Controller，充当数据转换器。它将Model信息转变为View信息，还将命令从View传递到Model

例如，假设我们有个包含date属性的unix格式模式（如1333832407）。Model不需要知道用户的日期View（如04/07/2012 @ 5：00 PM）,这里只是将地址转变为它的显示格式即可，Model仅保存原始格式的数据。View包含格式化后的日期，ViewModel充当两者之间的中间人。

在这个意义上，ViewModel可能被看作为Model，而不是View，但它可以处理大部分的View显示逻辑。ViewModel可能还会暴露一些方法，用于帮助保持View的状态，基于View上的操作来更新Model，并触发View上的事件。

总之，ViewModel位于UI层的后面。它暴露了View所需的数据（从Model那里），可以被视为View数据和操作的源头。

小结：

View和ViewModel之间通过数据绑定和事件进行通信。Model和ViewModel上的属性通过双向数据绑定进行同步和更新。ViewModel似乎是完全负责MVVM中的Model，但这种关系中有一些微妙之处值得注意。ViewModel可以为了数据绑定而暴露Model或Model属性，也可以包含接口，用于获取和操作在View中暴露的属性。

优缺点

优点：

缺点：

     MVP和MVVM均是MVC的衍生品。MVC与其衍生品之间的主要区别是每一层对其它层的依赖，以及它们是如何紧密地互相绑定的。

     在MVC中,View位于架构之上，与Controller相邻。Model位于Controller之下，因此View了解Controller，Controller了解Model。在这里，View能够直接访问Model。但是，向View暴露完整的Model可能会带来安全性和性能成本，这取决于应用程序的复杂性。MVVM试图避免这些问题。

     在MVP中，Controller的作用被Presenter所替代。表示器与View位于同一位置，监听View和Model的事件，并调解它们之间的行动。与MVVM不同，它没有使用将View绑定至ViewModel的机制，因此我们转而依赖每个View来实现用于让Presenter与View进行交互的接口。

     因此，MVVM允许我们创建Model的特定于View的子集，它们可以包含状态和逻辑信息，无需向View暴露整个Model。与MVP的Presenter不同，引用View时不需要ViewModel。View可以绑定到ViewModel上的属性，而属性会将Model所包含的数据暴露给View。如前所述，View的抽象意味着它背后的代码所要求的逻辑更少了。

     MVVM其中的一个缺点是：在ViewModel和View之间需要进行解释，这会带来性能成本。解释的复杂性也是可以变化的：它可以像复制数据一样简单，或是像View所看到的那种形式进行操作一样复杂。MVC没有这种问题，因为整个Model都是可用的，这种操作是可以避免的。