MVVM的一些理解

最新开始做一个新的项目，由于之前项目越来越大，后来有些类会变得特别臃肿。所以这次在开始之前想要研究一下其他架构。经过一番实践，抛弃了MVC，选择了MVVM。

但是不代表MVC不好，其实我个人更喜欢MVC，因为简单省事。如果你的项目没有那么大，没有那么多的业务逻辑。MVC最合适你了，不用考虑更换了。

首先，MVC和MVVM的区别，从字面上看似乎是把C变成了VM这么简单。其实不然，是把C拆分成了V和VM。不管什么模式，你放心VC肯定是存在的，只是尽量减少C的工作量，让他看起来更加轻量级，也可以称为是解耦。

假装这里有图。。。

M：Model数据层

V：视图展示

VC：只用于处理视图业务。初始化view和model，监听Model和view事件。作为桥梁传递事件。可以认为是MVVM里面的V

VM：viewModel抽离C里面的网络请求和业务逻辑，敲黑板！！业务逻辑。这里的viewModel看起来像是把View和Model绑定一块出来的。其实不然，这里面处理的是C的业务逻辑，不牵扯到任何View视图层的操作。所以尽量避免里面出现view实体。

这个时候问题来了，VM只处理业务逻辑吗？视图操作什么的逻辑呢？怎么办。

建议是少量的话还是VC里面处理，因为这样可以省很多事。如果比较多。那么咱们继续瘦身->ViewManager

ViewManager：处理视图上的操作逻辑。这个才是负责展示层的。可以把push跳转什么的也放到这里来。

优点：不多说，瘦身。

缺点：由于分离比较多。当你需要数据传递或者用户产生一些交互，跳转什么的。就需要用到协议或者block了。简单页面还好，如果页面很复杂，那么同样的，你的block量也会很大。当然，这个以后可以考虑做一个模板类，负责这些回调业务。

不管是MVVM，MVP，Viper还是别的什么模式，追求的都是高内聚，低耦合模式开发。但是实际上，这些架构都会使你的类的数量扩大好几倍。代码量也会相应增加。获得的收获就是页面逻辑看起来清晰了。耦合度没那么高了。实际运用过程中，还是需要根据你项目的大小来选择使用什么架构开发。当然，以上就是我理解的MVVM了。