浅谈MVC和MVVM

MVC本很美好，但到了iOS下变得不那么美好了，为什么这么说呢？
我眼里的MVC
M ：
Model 首先他不是实体，他主要作用是来处理业务逻辑的，他负责网络请求，组织数据，逻辑处理后通过XXX方式通知给VC。
V：
View很显然他只负责拿数据显示
C：
ViewController 拿Model加工好的数据供View显示，当中间协调者的作用

VC持有Model和View，因为是强依赖直接调用对象提供的方法
反而Model和View对VC没有依赖所以对VC的通信过程相对比较艰难
常用delegate,block,target-Action,protocol,KVO,通知等手段来通信

看起来挺好的，实际上也挺好
那为什么很多人说他不好呢，因为他们发现这种模式下VC变得很臃肿，
为什么会臃肿？
因为你没有严格执行MVC思想
因为很少有人单独给View弄一个层提供VC持有
为什么呢？
问题关键点是iOS里VC天然持有View，苹果也鼓励我们直接当这个View容器来上面添加子View
这就比较矛盾了，MVC让我们分3层，你们VC和View竟然在一起
这么以来VC里写很多关于View的代码
View的addsubview要写在VC里
View的action和实现逻辑要写在VC里
View的赋值也要写在VC里
那错在谁？
其实谁都没错，因为MVC其实提供的只是思想

因为VC直接持有View，平时开发中我们很少创建单独View类来管理View逻辑
所以VC的臃肿是避免不了（这里很多人以为VC臃肿是因为里面做了网络请求）
这种背景下出现了MVVM

MVVM
M：
Model 还是那个Model。
VM：
处理本应该VC处理的业务逻辑
View/VC：负责显示

再来跟MVC比较一下
Model View VC
Model ViewModel View/VC
整理下他们的区别
View和VC变一个后又多出了ViewModel
抛开表面上的区别我们真正要关注的应该是MVVM里弱化了VC的存在，强化了ViewModel
这是因为ViewModel抽离了VC的业务逻辑
那么问题来了为什么这么做呢？
仅仅是为了VC的瘦身？

要知道软件设计里复用思想是无处不在，即便你现在用不上，我们应该长远的角度上考虑，万一以后要用到呢？
MVC里我们无法复用VC，除非界面功能一模一样。但MVVM的ViewModel可以做到的
所以说MVVM的出现是恰恰解决这个问题
1.VC类天然持有View -》VC和View一起对待
2.VC逻辑无法使用 -》 VC逻辑抽离到ViewModel 通过ViewModel复用，‘顺便’给VC瘦身

当然随着时间推移对这些架构模式的理解也会有所不同，
这只是个人理解

继续
在MVVM的架构上大家习惯把网络请求放在ViewModel里然后Model当作实体使用，
个人理解的MVVM里这种操作是错误的，
因为VM只是是VC的逻辑抽离，VC本身不应该是发送网络请求，所以按这个逻辑VM也不应该发送网络请求。
可以简单的总结MVVM也是MVC，只是他的增强版本而已

当然不管mvc还是mvvm，不管你在哪里发网络请求，架构是死的人的思想是活的，
我们可以抛开架构的限制适当结合自己的业务做自己的发挥，当然这前提是要符合优秀的程序设计要求(面向对象的三大基本特征，五大基本原则)。