标准的数据解析：
什么是ResponseModel：对服务端下发数据的全量解析，使用第三方库MJExtension可以保证存在ResponseModel中的属性都是正确的值。
什么是BuisnessModel：面向业务层的Model，里面的属性专为View准备，对View来说是充分必要是数据，由多个ResponseModel或者一个ResponseModel中的一部分组装而成。
两种方式：第一种方式是为每一个View准备一个Model，第二种方式是一个Model中的数据能够展示多个View，我们一般在日常开发中第二种用的比较多。
标准的数据解析存在的问题：
-
可读性差
ResponseModel是与网络请求接口一一对应的（意味着命名似乎也要按照接口来命名），在不完美的情况下(特指服务端的数据很乱，或者在一些紧急迭代中，服务端没有时间去整理成客户端想要的充分必要数据)，就是出现脱离业务的状态，在下一个代码阅读者的眼中，除了详细的注释，很难直观的看懂这个Model的用意，而这样的Model散落在业务VC中，造成难以阅读的问题。
-
效率低
在以上流程中，
Dictionary -> Model1 -> Model2，通过三层转换才将服务端的数据转换成View所需要的数据。
水龙头式的数据解析：
Reformer是什么：改造器，将服务端的数据改造成view能用的充分必要数据。
为什么给View提供字典：
字典转字典 比 字典转Model更加有效率
数据结构具有通用性：与服务端沟通是，一般是用JSON格式的，基本沿用字典的形式，能一目了然的看到数据结构。
调试便捷：字典格式的数据在调试阶段，能直接po出数据格式。
怎么解决字典的Ke、y是文本式难以在编译时期保证正确性的问题：
在Reformer中改造数据时，.m文件中以
ReformerName + KeyName的格式实现Reformer改造后的数据的key。创建以
ReformerName + Keys为文件名的.h文件，将Reformer中的Key全部extern出去。如果不知道Reformer改造后字典中的key的，可以直接引用Keys文件，调用字典中的values。
水龙头式的数据解析的好处：
减少了数据转化的次数，提升了效率。
业务友好：数据转换的逻辑都被分散到了Reformer中，VC只需要选择不同的Reformer就可以了。
