@R0b1n_L33 文章关键点提炼到位！不得不承认，mvvm只是mvc的一个实践变种；神话它是错误的；但过分的贬低它也是不对的，因为框架本身都ok，只是使用的人理解和实践中抽象有问题，才导致mvc大家通常诟病的问题，mvvm现在被诟病的问题也是如出一辙，正如抽象出vm，但依旧有vm臃肿问题，依旧有轻m层的问题；至于mvvm引入rac且滥用，这个属于意外，因为rac本来也不是mvvm范畴里面的东西，rac的缺点更不是；不管是mvc、mvvm，抽象好了，都可以做到：纵向模块依赖，模块间低耦合；模块内横向分层，高内聚；
论MVVM伪框架结构和MVC中M的实现机制目录 MVC概论【本文】 模型层设计方法【请参考：http://www.jianshu.com/p/fce02188edec】 控制层的设计方法【请参考：https://ww...
@欧阳大哥2013 本篇主要是讲设计模式的，博主也花篇幅对不同层之间通信方式做了比较，也比较到位，但有点混乱；个人觉得可以从多个维度去阐述，因为你文中比较的delegete、block、kvo、notification在适用场景、解藕程度、设计模式、适用范围等都有差异；还有就是kvo本质上也避免不了松耦合问题，只是实践中代码组成放哪的问题；kvo如果不做二次开发，用在框架之间不同层通信这个场景，也是不能很好的解藕的；还有订单那块状态机的描述不太准确，只有事件输出，没有事件输入；
iOS的MVC框架之模型层的构建这篇文章是论MVVM伪框架结构和MVC中M的实现机制的姊妹篇。在前面的文章中更多介绍的是一些理论性质的东西，一些小伙伴在评论中也说希望有一些具体设计实践的例子，以及对一些问题...
纠正两个笔误：1、userManager到底是啥，其实很简单，如果是对数据本身的“输入输出”做业务逻辑处理
2、个人觉得主要参考原则就是，这块看似模型相关的逻辑，逻辑和上层具体业务场景有关么？会对未来m层的相对稳定性和高可复用性有影响么？答案否定的话就倾向于归属于m层
iOS的MVC框架之模型层的构建这篇文章是论MVVM伪框架结构和MVC中M的实现机制的姊妹篇。在前面的文章中更多介绍的是一些理论性质的东西，一些小伙伴在评论中也说希望有一些具体设计实践的例子，以及对一些问题...
@醉江月 月月同学对mvvm的这个理解是没毛病的；实践中，mvvm其实是离不开c的，只是vm给c减负了，c主要关注v的创建，c的生命周期相关处理、事件回调等处理，而vm处理原来写在c里面的数据和视图关系的处理部分；但博主一直强调的vm层，是抽象出来做v和m双向绑定的，这个也是没毛病的，这也是理论上来说，mvvm中m和v是相对稳定的，且可复用，没有耦合关系，而vm是相对不稳定的，基本没有可复用性；另一个角度，iOS一谈起mvvm必然绕不开rac，就是因为iOS本身是缺乏一个较友好的双向绑定通信机制的，直接使用kvo并不友好，所以才有了函数式范式的rac，这点也印证了vm做双向绑定这个事；只是实践中，很多时候双向绑定互相通信，很多人写在了vc中，代码表现上很多时候也很像是让vm和view互相通信了，但背后其实很经典的一个场景是：是用户通过v做输入，通过vm告知了m，驱动数据变化；m发生变化，再通过vm告知v，驱动v显示上的变化，所以这个主要取决于对模式的理解后，怎么去抽象和代码设计了；二位争议最大的是，博主的userManager到底是啥，其实很简单，如果是对数据本身的输入做业务逻辑处理，数据本身需要的服务和能力，不涉及某个具体v层场景的，属于m，大概能对应上博主一直强调“业务模型”；如果是针对数据做某个显示场景需要的加工，属于vm层；从博主目前贴出来的userManager代码，更接近m层；所以这块其实是容易有边界模糊的地方的，个人觉得主要参考原则就是，这块逻辑和上层具体业务场景有关么？会对未来m层的相对稳定性和高可复用性有影响么？答案否定的话就倾向于归属于vm层；不管mvvm、mvc，只是一个思想，重点在于实践中解决了什么问题，比如UI和数据隔离、业务有较清晰分层、模块化解藕、可单测等，就达到了模式应用的价值
iOS的MVC框架之模型层的构建这篇文章是论MVVM伪框架结构和MVC中M的实现机制的姊妹篇。在前面的文章中更多介绍的是一些理论性质的东西，一些小伙伴在评论中也说希望有一些具体设计实践的例子，以及对一些问题...
