其实不论是MVC、MVVM或是MVP，不过是见仁见智，各有各的解释，不同的划分铸就了不同的程序结构。
对于开发者来说MVC应该再熟悉不过了，为什么要拿来写呢，
因为总是经常看到有人以这样错误的姿态描述MVC，Model改变后直接修改View展示数据：
我觉得这张结构图并不能完全代表MVC，至少在IOS／MacOS的开发中是不符的，所以写这篇文章阐述下我的理解，从乔布斯的老员工Paul Hegarty的表述中（MVC讲解）可以知道，在Apple的设计里，MVC中的Model指的是程序的模型层（就是程序数据模型，进行数据运算、核心数据逻辑的这一层），而非ViewModel，或许把他形容为ProgramModel或许更合适。MVC中的View和Model是完全隔绝的，可以看下面这张图：
下图是Stanford CS193P课程中Paul Hegarty老师课件里的一张图片，重点是：view do not own the data they display，就是说，Model is Model，not ViewModel
当中的双黄线隔离了Model和View，View严禁持有和直接与Model通信，这保证了View的独立和可复用，这是MVC最重要的特点之一。View不能直接操作Controller，但可以通过delegate或者action来发送信息通知其他地方自己的状态改变；Model同样看不到Controller，一般只通过Notification或者KVO来通知其它地方自己的改变。
网易公开课上有Paul Hegarty的课程，MVC结构讲解得非常细致，这里就不做赘述了，想要详细了解的同学可以打开然后快进跳到视频的第58分钟开始讲解MVC：
也许有同学还不太明白ViewModel与Model的区别，举栗说明：
假设我们现在要制作是一个 滑动条，滑动条是一个UI组件，UI上就是画一个滑动槽和一个表示当前位置的圆形如下：
这个滑动条可以表示一个百分比，也可以被设置当前的状态。
假设滑动槽的左侧顶点时原点，
获取当前百分比时，只需要先得到圆形X轴的位置，然后X除以滑动槽的长度就得到了滑动条当前表示的百分比。
设置当前百分比时，比如设置一个50%，只需要用滑动槽的长度乘以50%，得到圆形的X轴位置，放置圆形就可以了。
但这样设计的话，会有很多问题。比如，当数据被频繁获取的时候，滑动条就需要不断的进行几何运算，或者连续非常多次被设置为同一个百分比数值时，UI原本不用变化，却被重新绘制了非常多次。或者当我们要将这个滑动条所表示的数据从百分比变为0到200时，就需要重新写绘制算法。
怎么解决这些问题呢？就是为它添加一个ViewModel
首先，为滑动条添加一个float类型名叫value的私有变量，
滑动条绘制时，从value读取数据获取圆形的位置信息，
外部从value获取当前进度，
外部要修改进度条状态，修改value，若被修改为与原来不同的值，则重绘滑动条状态。
要实现滑动条可以表示0-200的值，可以把一个value变为一个两个变量，如value和range，再加上一个算法通过这两个值计算圆形位置。这个变量加上算法就组成了一个模型，这个模型就是这个View的ViewModel。（当然，从另一个角度也可以把这个滑动条组件理解为一个MVC，那么滑动条的UI就是View，读取value和给圆形赋予X轴位置的操作就是Controller，value和range就组成了Model）
准备把这个滑动条组件拿来使用，用它来控制屏幕亮度：
创建一个Controller，它可以修改和获取屏幕亮度，还持有一个滑动条组件，
屏幕亮度有变化时，通知Controller，Controller修改滑动条的状态，
滑动条被滑动时，通知Controller，Controller修改屏幕亮度。
屏幕亮度（Model），滑动条（View）和Controller和就组成了一个MVC。
这里的屏幕亮度数据就是该系统中的Model。滑动条组件是一个单独的View，滑动条组件中的value是滑动条组件的ViewModel。
当然，你也可以根据不同的角度给予不同的阐述和理解。
不同的阐述角度可以给予项目不同的设计结构。
值得提出的是，我看到有些同学在Controller中拿到Model的数据时，依然需要做很多数据转换、处理的工作，而这些代码把Controller变的异常沉重。
这时，也许可以反思一下，这些数据转换的工作是不是可以把它们设计到Model中更合适呢？
