mvvm

最近前端圈子里面，发现大家都在热炒概念，什么knockout，angularJs，都被捧成神了，鄙人不才，最近心情也不好，特地写这篇文章来找骂

写代码的码农都知道，Java社区虽然不是一个提出分层思想的，确实贯彻的最好的，如今是个Java开发都不会不知道SSH的开发模式，从MVC到MVVM的概念的热炒，其实真没什么技术进步

（如果你觉得本文言辞激烈，过于愤世嫉俗，实在看不下去，欢迎移步另一位园友的分层进化史科普文章http://www.cnblogs.com/indream/p/3602348.html）

先看什么是MVVM

View一般就是我们平常说的HTML文本的Js模板，里面可以嵌入一些js模板的代码，比如Mustache，比如jstl类似的模板伪代码

ViewModule层里面就是我们对于这个视图区域的一切js可视业务逻辑，举个例子，比如图片走马灯特效，比如表单按钮点击提交，这些自定义事件的注册和处理逻辑都写在ViewModule里面了

Module就更简单了，就是对于纯数据的处理，比如增删改查，与后台CGI做交互

那么什么是MVVM框架呢？？一般他们都是这么做的

1. 定义一串所谓的伪模板代码，例如通过className标注，或者自定义tag的方式，将一段html文本区域给标注声明起来，意思就是喊一嗓子，“喂，兄弟们，这块地方我占了，要拉屎去别处拉去”

2. 通过类似jstl之类lamda表达式，来做js模板，“拜托伙计，天堂有路你不走，非要自己搞一套，你就不能暴露接口让大家用自己的模板语言，比如Mustache或者jtpl吗？”

3. 很傻比的封装一串自己的所谓数据模块组件，与不同类型的数据源做数据传输和适配，一般都不会分层很清晰，加入后台数据字段改了，写框架的都没脑子的，从来不做数据字段的自定义适配（举个例子，原来后台传递的字段是person.userName，现在改成了小写，person.username，你就傻逼的去吧模板再改一下吧，其实要解决这个问题，非常简单，在MVVM层中引入一层DO，领域对象层，Module到DO之间还有一层转换就可以搞定这个问题）

4. 非不暴露自己的自定义事件模型，就是那个观察者模式啦，自己乱七八招在页面上绑定一堆form change之类的事件，以实现View与Module的单向绑定

5. 所谓的双向绑定，也就是OOP语言中早被烂透了的getter，setter模型，ES5+可以用defineProperty，低版本就需要自己在js object赋值的时间做写死代码方式的处理了

我们再来看细节

1. 双向绑定

号称是最难理解的地方，其实是框架的作者根本就没理解Java社区对于软件开发分层理解的精髓

标准的数据驱动开发，应该如上图所示，在一个View的生命周期内，一个ViewModule会管理一个DomainObject（业务模型），一个DO可能包括多个Module数据模型，一个Module可能来自多个数据源，而不是想很多所谓的MVVM框架那样强迫一个M来一个数据源

按照上图标准分层方式来划分的好处，在于，逻辑清晰，Module层粒度够细，可以被多次复用

DO层与VM层View层属于一一对应关系，方便对数据做增删改查的同步

每一层应该是独立的，非一定要使用MVVM框架的紧耦合，可以用自己使用不同的js插件或者模块实现MVVM

我们抛弃框架，单纯的看数据，其实我们要解决的问题很简单

a) 当DO对象属性放生变化时候，通知View更新

b) 当View上表单值放生变化时，通知DO更新，并异步通知队列同步到数据源

先来看问题a，这个最简单，DO是一个基本的Javascript Object，我们在View上的模板显示是这个Object.property，

改变一个Object对象的方式无非几种，一种是

a) 显示Object.property = ‘我是傻逼’

b) xxxx.methodName(Object, ‘property’, ‘我是傻逼’)

c) xxxx.merge(Object, {‘property’: ‘我是傻逼’})

如果是a的情况，ES5+，可以通过设置Object.defefineProperty(‘property’,{set: functiono(){},get:function(){}})，来做赋值和取值的监控触发

对于IE8一下，因为js不支持运算符重载，所以暂时没有好的办法，所以如果只考虑移动端的话，直接defineProperty就全部搞定，如果是要考虑PC的话，就不建议开发者使用直接赋值的方式，参考java的开发模式，也是推荐OOP时候，使用set方式赋值，而不是直接=赋值

当然了，如果你非要兼容IE8一下的话，用定时器做轮训，配合for in 反射，通过脏数据与原始备份对比的方法也是一种办法，不过这种办法在当前页面非常耗性能，由于IE8一下不支持多线程，HTML5 worker，如果未来flash 插件支持多线程的话，倒是可以用js和flash插件做线程交互的方式做脏数据检测

如果是b的情况，那就太简单了，在methodName里面触发对于该属性修改的回调即可，如何注册回调呢，首先我们要实现一个类似Dom Event的自定义对象的Event模型，然后通过类似Dom Event的注册事件方式，注册观察者，订阅事件，当执行了methodName时候，发送消息，通知所有订阅者执行回调

如果是c的情况，类似b一样处理

这样一看，双向数据绑定的问题就非常简单的解决了

我们再来看另外一个MVVM的问题，非简单数据模型，复合数据模型（DO的属性值不是一个string，而是一个Object，且这个Object可能还嵌套多层Obejct的时候）的处理办法，这个一般的MVVM框架直接不考虑，或者通过长字段名的方式绕过这个问题

这个问题是这样的，早在10几年前，java structs框架流行的时候就出现了，当一个表单，出现需要对两个Java Bean做update操作时候，一个bean是user，一个bean是成绩

对应的表单字段名，就是 user表.name，user表.id，score表.point，

在struct2里面，处理逻辑是把 “点”作为特殊符号，在做form序列化时候，非包含点的字段的值都是string，包含点的字段是一个Object，比如刚才的form序列化之后结果就是 { user: {id :’’ , name: ‘’}, score: {id: ‘’, point: ‘’}}

同理在MVVM实现时，也是一样，认为点是分割对象的关键字，这样我们就可以实现把多个对象嵌套到View模板里面，实现复合Object的双向映射

最后一个问题，也就是高级MVVM编程里面必须要面对的问题，就是自定义事件的广播和冒泡，我看过大多数的MVVM框架，对于广播，这块有部分实现了，但是对于冒泡一个都没实现

其实这个真的不是很复杂的问题，事件广播，这个最简单，三岁小孩都能写，我们在注册回调时候，不是有一个事件队列吗，在回调时候，通过特殊标记位，控制是否继续扩散广播，还是执行完毕终止即可

而自定义事件的冒泡要骚骚复杂一些，他是由于OOP编程里面的继承和包含关系引申而来的，我们先说包含关系，前面说了MVVM框架里面，都会声明一块地方为VM控制区域，一般垃圾的框架都不会考虑，VM嵌套的情况，因为图简单吗

但是实际开发过程中，你会遇到很多这种情况，就是VM复用的问题，一般都是发现使用了MVVM框架之后，发现VM定义的太大，没法复用，如果要复用VM就又发现VM定义的太小，出现需要VM嵌套的情况没法用

其实简单，我们知道DOM事件是有冒泡的，VM同理，只要在自定义事件模型里面定义了VM的父子关系，或者同级关联关系，即可实现VM的自定义事件的广播和冒泡，另外也解决了VM复用的问题，可以让代码颗粒度更小

 

 

使用WPF+Mvvm开发一年多，期间由于对Mvvm模式的理解不足，遇到了很多问题，也绕了很多弯子；网上提供的Mvvm的示例比较简单，实际项目中的需求也各种各样。
不过经过几个项目，也有了一些对Mvvm模式的理解：

1. Mvvm是什么，Mvvm是怎么来的？
Mvvm模式广泛应用在WPF项目开发中，使用此模式可以把UI和业务逻辑分离开，使UI设计人员和业务逻辑人员能够分工明确。

Mvvm模式是根据MVP模式来的，可以简单的说，Mvvm模式就是WPF版的MVP模式。MVP模式，MVC模式，这几个模式都是为了抽离出UI逻辑和业务逻辑。

2. 使用Mvvm模式可以参考的主流框架及简单介绍。
主流开源框架：Simple Mvvm，Mvvm Light和Prism。
Simple Mvvm和Mvvm Light基本一致，都是对Mvvm模式的基础封装，并加入了一些不错的功能，消息传输机制，依赖注入等等。开发中小项目推荐使用这两个的其中一个。
Prism是微软给出的一个Mvvm框架，不过它的关注点不仅仅是Mvvm模式，我觉得主要是模块的思想更多一些。大项目的话才推荐使用这个框架，比如一个系统需要分为N个团队进行不同模块的开发，然后再组织成一个系统。

3. 使用Mvvm模式的思想分析问题。
现在有一个功能：用户填入姓名，年龄，选择最喜欢的颜色，然后点击确定按钮提交。就是这样简单的一个调查表。
a.首先设计UI，UI看起来可能是这样的：

b.根据UI去设计对应的ViewModel层需要那些属性，数据和命令：

　Name:string 　Age:int 　FavoriteColor:string 　Submit:Command

c.在ViewModel层的SubmitCommand命令中，调用Model层的Submit方法进行逻辑处理。Model层看起来可能是这样的：

　public string Name { get; set; }
　public int Age { get; set; }
　public string FavoriteColor { get; set; }
　public void Submit() { ... }

4. 看到的一些对Mvvm模式的看法，觉得不太正确。
a.Code-Behind文件要保证绝对干净。
这个说法有些太绝对了，理想状态下，View层的Code-Behind文件中只有在构造函数中调用初始UI元素的一行代码及设置View层的DataContext为对于的ViewModel层。
其实，Code-Behind中还可以些一些UI的逻辑的，比如一些丰富的动画效果，或者直接设置某个元素的样式等。
不过，Code-Behind中确实是不可以写业务逻辑的。
b.ViewModel层不能是Model层的简单封装，ViewModel层也不能是View层的简单映射。ViewModel层和View层要绝对分离，ViewModel层要和View层一样去面向需求设计。
我觉得这样做有点太过了。
Mvvm的目的只是为了UI逻辑和业务逻辑的分离，你说业务逻辑和数据要写在哪一层呢？没错，Model层。
ViewModel层的主要责任是表现逻辑和状态，即ViewModel层是连接View层和Model层的。Model层的一些业务逻辑的状态是需要通过ViewModel层暴露给View层来反映给软件使用者的。

5.我对WPF+Mvvm模式开发的一些经验。
a.WPF的几个重要概念要熟练理解和运用：模板，依赖属性，数据绑定。和Mvvm模式的结合使用，能发挥出很好的效果。
b.团队中的成员最好能够对Mvvm模式有统一的理解和认识。
c.Mvvm模式只是一个模式而已，不是有了Mvvm模式就能写出优美的代码，涉及到具体的业务逻辑，还是需要你以及你的团队有足够强的设计能力。