搬砖的时间总是过的很快，在新环境已满一个月了。想想之前找工作面试时被各种问题问的发愣时的种种尴尬，想想关键还是自身的原因。因为在上份工作期间只顾着学习新的知识点而没有花时间去做深入总结. 有了之前的教训应当引以为戒。
当然该文章主要目的并不是发牢骚。而是在这一个月内自己对MVVM的一个接触和大致的理解。虽然我一直很怀疑对于一年多点的经验的我现来才开始理解MVVM是否已晚，但我始终坚信学了总没有错！
之前是一直沉浸在自我认为的MVC中，对于MVC的理解还是远远不够的，也没有花时间去深入理解过，只是在大致的理解同时在项目中自我认为比较合理的去实现模块的分离工作。
低耦合
经过一些Blog的阅读和实践，在低耦合上我是这么理解的:少写重复的代码,利用现有的资源实现相同的功能。就拿TableView的实现来说Delegate和DataSource 是必不可少的，在MVC中我会一股脑的在ViewController中去实现它们，然后在其他的类中重复着相同的事情。这显然不是低耦合
而在MVVM的实现中我却发现真正低耦合的其实只有DataSource。因为对于Delegate部分方法在不同功能的TableView实现中是不一样的。而DataSource的实现却是很固定的，简单点说无非就是多分区和单个分区的区别以及cellForRowAtIndexPath的内部实现了。这些实现完全可以通过一定的方法固定实现。
当然Delegate也可以，但是相对于DataSource只有几个主要的方法来说Delegate是相当不稳定的。因为在平时的项目中Delegate的方法使用率相对比较是更高的。又比如didSelectRowAtIndexPath的方法又不得不从新回到ViewControll中来实现点击的跳转。
按照MVVM设计思路，被重用的是ViewModel，而改变内容的其实只有Model。Model多半只涉及到数据跟操作是没有多大关联的。
开发需求
MVVM出现有个作用是为了解决在MVC中厚重的ViewController。但是以我目前的接触过的项目来说我并没有碰到过这种情况，因为目前的模块功能并不会复杂到不得不在ViewController内写过超千行的代码量。即使如此我想很多人都会绕过采用更优的方法来实现。
其实以上几点并不是对MVVM的排挤，相反而是一种对比和理解。每个设计模式都有自己有优缺点，哪种更适合自己的项目、更容易维护当然只有自己最清楚了。