標(biāo)準(zhǔn)的數(shù)據(jù)解析：
什么是ResponseModel：對(duì)服務(wù)端下發(fā)數(shù)據(jù)的全量解析牢酵，使用第三方庫MJExtension可以保證存在ResponseModel中的屬性都是正確的值。
什么是BuisnessModel：面向業(yè)務(wù)層的Model疏橄，里面的屬性專為View準(zhǔn)備摇予，對(duì)View來說是充分必要是數(shù)據(jù)，由多個(gè)ResponseModel或者一個(gè)ResponseModel中的一部分組裝而成晌坤。
兩種方式：第一種方式是為每一個(gè)View準(zhǔn)備一個(gè)Model程奠，第二種方式是一個(gè)Model中的數(shù)據(jù)能夠展示多個(gè)View丈牢，我們一般在日常開發(fā)中第二種用的比較多。
標(biāo)準(zhǔn)的數(shù)據(jù)解析存在的問題：
-
可讀性差
ResponseModel是與網(wǎng)絡(luò)請(qǐng)求接口一一對(duì)應(yīng)的（意味著命名似乎也要按照接口來命名）瞄沙，在不完美的情況下(特指服務(wù)端的數(shù)據(jù)很亂己沛，或者在一些緊急迭代中慌核，服務(wù)端沒有時(shí)間去整理成客戶端想要的充分必要數(shù)據(jù))，就是出現(xiàn)脫離業(yè)務(wù)的狀態(tài)申尼，在下一個(gè)代碼閱讀者的眼中垮卓，除了詳細(xì)的注釋，很難直觀的看懂這個(gè)Model的用意师幕，而這樣的Model散落在業(yè)務(wù)VC中粟按，造成難以閱讀的問題。
-
效率低
在以上流程中霹粥，
Dictionary -> Model1 -> Model2灭将，通過三層轉(zhuǎn)換才將服務(wù)端的數(shù)據(jù)轉(zhuǎn)換成View所需要的數(shù)據(jù)。
水龍頭式的數(shù)據(jù)解析：
Reformer是什么：改造器后控，將服務(wù)端的數(shù)據(jù)改造成view能用的充分必要數(shù)據(jù)庙曙。
為什么給View提供字典：
字典轉(zhuǎn)字典 比 字典轉(zhuǎn)Model更加有效率
數(shù)據(jù)結(jié)構(gòu)具有通用性：與服務(wù)端溝通是，一般是用JSON格式的浩淘，基本沿用字典的形式捌朴，能一目了然的看到數(shù)據(jù)結(jié)構(gòu)。
調(diào)試便捷：字典格式的數(shù)據(jù)在調(diào)試階段张抄，能直接po出數(shù)據(jù)格式男旗。
怎么解決字典的Ke、y是文本式難以在編譯時(shí)期保證正確性的問題：
在Reformer中改造數(shù)據(jù)時(shí)欣鳖，.m文件中以
ReformerName + KeyName的格式實(shí)現(xiàn)Reformer改造后的數(shù)據(jù)的key。創(chuàng)建以
ReformerName + Keys為文件名的.h文件茴厉，將Reformer中的Key全部extern出去泽台。如果不知道Reformer改造后字典中的key的，可以直接引用Keys文件矾缓，調(diào)用字典中的values怀酷。
水龍頭式的數(shù)據(jù)解析的好處：
減少了數(shù)據(jù)轉(zhuǎn)化的次數(shù)，提升了效率嗜闻。
業(yè)務(wù)友好：數(shù)據(jù)轉(zhuǎn)換的邏輯都被分散到了Reformer中蜕依，VC只需要選擇不同的Reformer就可以了。
