前言
之前我们为view引入了wrapperSet的概念，想以此解决view局部刷新问题，后来发现这个方案不太合理
view里面插入了业务相关的代码，事实上这个是应该剥离出去，业务的需求千奇百怪，我们不应该去处理
view现在只提供最基础的功能：
① 定义各个状态的模板
② 渲染模板
整个view的逻辑便该结束了，有一个比较特殊的情况是，当状态值不变的情况就应该是更新，这个可能会有不一样的逻辑也应该划出去
Adapter的意义在于存储view渲染过程中需要的data数据，从组成上分为
① datamodel
② viewmodel
datamodel用于具体操作，viewmodel被干掉了，提供一个getViewModel的方法替换，并且对外提供一个format方法用于用户继承
format的参数便是datamodel，这里通过处理返回的数据便是我们所谓的viewModel，他将会用于view生成对应html
然后datamodel的改变会引起对应view的变化，这个变化发起端与控制端皆在viewController，最后viewController会通知到view重新渲染
Controller依旧是交互的核心，他是连接Adapter以及view的桥梁
view与Adapter本身并没有关联，Controller将之联系到了一起：
① 在实例化时候便会关联一个Adapter以及view的实例，这里Adapter不是必须的
② viewController会保留一个view的根节点，view的根节点只会存在一个
③ viewController会在Adapter实例上监听自身，在adpter datamodel发生变化时候通知到自己，便会触发update事件
④ 传入初始状态的status以及Adapter的datamodel，调用view的render方法，会生成当前状态的view的html
⑤ 将之装入view的根节点，并且为viewController的this.$el赋值，create的逻辑结束
⑥ 触发viewController show事件，将events绑定到根节点，将$el append到container容器中并显示，初步逻辑结束
⑦ viewController有几个事件点用于用户注册，本身也具有很多一系列dom事件，可能导致datamodel的变化
⑧ 若是Adapter的datamodel发生变化便会触发dataAdpter改变的notify事件，这个时候viewController便会有所反应
⑨ datamodel的改变会触发viewController的update事件，默认会再次触发render事件重新新渲染结构
由于render会放给view自定义，所以其中需要执行的逻辑便不需要我们的关注了
实例
这个便是一个标准的MVC模型，借IOS MVC的模型来说
核心操控点在于Controller，Controller会组织model以及view
由于Controller上注册的各系列事件，会引起model的变化，
每次model产生变化后会重新通知，Controller 通知view update操作
这个时候view会获取viewController的状态值以及model的数据渲染出新的view
view只负责html渲染
model只负责操作数据，并且通知观察者改变事件
Controller将view以及model联系起来，所有的事件全部注册至Controller
PS：传统的View会包含事件交互，这里放到了Controller上
模型会把datamodel的改变通知到控制器，控制器会更新视图信息，控制器根据view组成dom结构，并且注册各种UI事件，又会触发datamodel的各种改变
这就达到了理想情况的view与model的分离，一个model（adpter可用于多个viewController），一个dataAdpter的改变会影响两个视图的改变
这个MVC可以完全解耦view以及model，view的变化相当频繁，若是model控制view渲染便会降低model的重用
这里首先举一个例子做简单说明：
完成HTML
underscore-extend
Util
完整MVC想法
代码效果如下：
每次点击刷新数据时候会模拟一次Ajax操作，将datamodel中的数据改变，然后会触发视图改变
1 events: {
2 'click .cui-btns-sure': function () {
3 var data = this.$el.find('#ajax_data').val();
4 data = eval('(' + data + ')');
5 this._handleAjax(data);
6 }
7 }
1 _handleAjax: function (data) {
2 this.setViewStatus('loading');
3 this.adapter.ajaxLoading();
4 getAjaxData($.proxy(function (data) {
5 this.setViewStatus('ajaxSuc');
6 this.adapter.ajaxSuc(data);
7 }, this), data);
8 },
ajaxSuc: function (data) {
this.datamodel.ajaxData = data;
this.notifyDataChanged();
}
中间又一次状态变化，将视图变为loading状态，一次数据请求成功，我们要做的是，重写viewController的render方法
1 render: function (data) {
2 //这里用户明确知道自己有没有viewdata
3 //var viewdata = this.adapter.getViewModel();
4 var wrapperSet = {
5 loading: '.cui-error-tips',
6 ajaxSuc: '.cui-error-tips'
7 };
8 //view具有唯一包裹器
9 var root = this.view.root;
10 var selector = wrapperSet[this.viewstatus];
11
12 if (selector) {
13 root = root.find(selector);
14 }
15
16 this.view.render(this.viewstatus, this.adapter && this.adapter.getViewModel());
17
18 root.html(this.view.html);
19
20 },
这块逻辑需要被用户重写，因为具体每次渲染后，形成的html装载在什么位置，我们并不能确定
这里我们再写一个例子，看一看共享一个Adapter的效果
View Code
可以看到，上下的变化根源是数据操作，每次数据的变化是共享的
结语
今天更正了上一次留下来的wrapperSet思维，这里对自己所知的MVC做了一次梳理
然后框架在一次次修改中逐步成型了，是个好现象，慢慢来吧
本文转自叶小钗博客园博客，原文链接：http://www.cnblogs.com/yexiaochai/p/3749734.html，如需转载请自行联系原作者
