MVC, MVVM一点感受

打从这个世纪初开始进入界面编程起，就一直接触MVC，最近学习js前端框架，到处都是MVVM。

结合这些年各种类型的项目经验，谈谈自己的感受。

（编程解决问题的核心思路就是增加层，通过层来解耦原来强耦合的两边，这个层通常是基于接口(或者事件)）

故事的主角肯定是V和M，M是程序的基础，随着计算机图形界面的发展，V也应运而生，M更加偏逻辑，V更加偏展示、显示、控件、渲染、表现。

二者需要的技能集是有差异的。逻辑代码测试方便，编写效率高。而视图代码，编写-测试-修改-验证循环通常比较慢，做相应开发的同学，对设计通常需要有点感觉。

有了V之后，用户针对V的需求就千奇百怪的提出来了，V的代码经常被各种修改，这时根据设计原理，就会简单地把View和Model分离，View直接调用Model还好，但是Model修改的时候，直接通知View，看起来是不能接受的，在正常的逻辑代码里，要更新按钮位置，更新界面颜色，这种双向依赖就是强耦合。为了解耦，在V和M之间需要引入一个C，M发生变化的时候，给C发送事件，至于C怎么处理这个事件，M就不需要管了。

基础的MVC大致逻辑差不多是这样

View.ReadUserInput()->Controller.OnUserInput()->Model.ProcessInput()->Model.UpdateInnerData()->Model.FireDataChangedEvent()->Controller.OnDateChangedEvent()->View.Update()

这个过程中还会涉及到model的数据发生变化是主动推还是被动拉，View是局部更新还是整体更新，甚至不同的MVC角色之间，如果是跨语言的，那么是否需要增加新的层？

比如在进行网页开发的时候，服务器端的Model可能是Java，但是前端的显示可能是HTML，这个时候就需要不断来看问题。

比如做JSP开发经常就会有VO，就是ViewObject，就是把业务处理的结果，转化为页面显示需要的数据对象，然后把这个对象传递给客户端显示，这时还只是VO，还不是VM，有时候，View的控件(html的imput等控件）的修改要同步到VO，那么这个VO就是VM了，只有在JS中，JS对象通过框架（比如angularjs,knockoutjs,avalon）与HTML控件进行了双向的绑定，那么才是VM，VM最大的好处就是把对View的操作转化为对M的这种逻辑操作，便于开发测试。

在这种MVVM的前端框架中，V是HTML的标签，VM是Javascript对象，算是HTML的View在JS语言中的代理，使得JS中处理的是js对象，而不是dom对象。MVVM中的M，就是用来填充VM的数据，比如从服务器端异步加载的json,异步加载的html片段，甚至服务器端jsp/servlet直接生成的js代码数据。

这种MVVM只是前端框架，因为有了一个和V能够双向数据绑定的VM，VM最大的好处是把View的开发转化为M的开发。

MVVM的核心是双向数据绑定技术，适合格式化数据的显示，对于游戏，就不太适合。

游戏通常是典型的MVC，Controller.ReadUserInput()->Model.Update()->View.Render()。只不过有的时候，Model的变化过程跟View也是耦合比较紧密的，需要引入ViewObject概念。举个例子，比如游戏中，服务器端开了一个宝箱，宝箱的物品从逻辑上应该归属于玩家，但是客户端需要播放物品掉落，等用户拾取了，或者时间到了，才显示加给用户，这个时候可能就需要VO。

此外，对于Model，可能涉及到很多歌Model，因此可能需要引入DomainOjbect或者BusinessObject来聚合Model对外提供服务。Model聚焦于增删改查，BO聚焦于业务层面，聚焦于调用方。一个实际中完整的结构，可能有如下几层：View->ViewObject->Controller->Service->Model->DataSource

View负责渲染显示，ViewObject是渲染层对应的数据，Controller接收各种事件，Service负责业务逻辑，Model负责模块逻辑，DS负责数据的存取。