浅解MVVM模式

以前工作中遇到问题解决后，没有系统的整理过，所以有时候会再次遇到这些问题，还是需要再重新在网上查看资料，所以最近这几天就准备现在CSDN上开始写博客，记录自己解决的问题，分享给大家，对自己也算是一种鞭策和学习吧。废话不多说了，咱们直接来说下这个。关于MVVM我自己前段时间也是第一次接触，所以我在网上查了许多的资料，加上自己的一些理解，下面就是我自己的关于MVVm模式的一些整理。
总体上我个人是感觉，除非你一个界面有较多的代码，或者是逻辑性非常的页面是非常有必要用到这个模式的，但是如果界面不是很复杂，代码也比较少，用这个无疑增加自己的工作量，这也就是用到MVVM模式的利弊，这个我下面会具体介绍的。

首先先基本了解下MVVM模式：MVVM模式是由MVC慢慢演变而来的一种新型的架构，即模型-视图-视图模型（MOdel-View-ViewModel）ViewModel将Controller的业务逻辑和页面逻辑等剥离出来，减小Controller的职责和复杂度，使不同层级的职责更加明确，耦合性更低，代码的阅读性、重用性、可维护性更高。相比起MVC，MVVM多了一个ViewModel，即视图模型，对视图展示数据进行处理，接受Controller的事件命令请求及处理相关数据，之后将数据处理好交给Controller展示到View上。数据层可以复用，便于封装和重用。简单来说，就是API请求完数据，解析成model，之后在viewModel中转化成能够直接被视图层使用的数据，交付给前端。

具体的要怎么实现呢

model层
主要是放一些数据中的一些字段，将它放在model中便于自己取用。

viewModel 层
viewModel层是我们处理业务逻辑的核心层，在这里我们需要发起网络请求（如果网络请求较多，可以抽出来，只在ViewModel里调用）、解析数据、转换数据给前端。viewModel中将API返回的数据解析成model，并将model转化成可供view层直接使用的item，将item交付给前端使用。经过viewModel转化之后的数据item由viewModel保存，与数据相关的处理都将在viewModel中处理。

至于MVVM的缺点这里引用Casa Taloyum大神的博客中写的

这种做法是能够提高后续操作代码的可读性的。在比较直觉的思路里面，是需要这部分转化过程的，但这部分转化过程的成本是很大的，主要成本在于：
* 数组内容的转化成本较高：数组里面每项都要转化成Item对象，如果Item对象中还有类似数组，就很头疼。
* 转化之后的数据在大部分情况是不能直接被展示的，为了能够被展示，还需要第二次转化。
* 只有在API返回的数据高度标准化时，这些对象原型（Item）的可复用程度才高，否则容易出现类型爆炸，提高维护成本。
* 调试时通过对象原型查看数据内容不如直接通过NSDictionary/NSArray直观。
* 同一API的数据被不同View展示时，难以控制数据转化的代码，它们有可能会散落在任何需要的地方。

针对这些缺点，Casa Taloyum大神也提出了相应的解决方法，即用一个类似reformer的对象进行数据过滤，根据不同的reformer对象过滤出不同的数据。这种方法我还没有尝试过，后期会继续使用，估计就会用到这些方法，到时再来更新这篇博客。