越來越多的項(xiàng)目使用CocoaPods，使用CocoaPods很有可能會用過JSONModel。
JSONModel是個(gè)很強(qiáng)大的庫，只要根據(jù)JSON定義好對應(yīng)的類并繼承JSONModel，就可以把JSON字符串轉(zhuǎn)成該對象，而且對數(shù)據(jù)的轉(zhuǎn)換還有很強(qiáng)的兼容性，比如跨層解析。如下示例：
JSON字符串是這樣的：
{
"articleId":"12314",
"author":{
"name":"xiaofang",
"icon":"http://......"
}
}
類定義是這樣的：
@interface ArticleInfo : JSONModel
@property NSString *articleId;
@property NSString *authorName;
@property NSStirng *authorIconUrl;
@end
“articleId”解析自然沒問題，“authorName”和“authorIcon”就需要指定解析規(guī)則了，如下：
+ (JSONKeyMapper *)keyMapper
{
return [[JSONKeyMapper alloc] initWithDictionary:@{@"author.name": @"authorName", @"author.icon": @"authorIconUrl"}];
}
以上可以看出JSONModel是相當(dāng)強(qiáng)大的，可以把服務(wù)器給的JSON數(shù)據(jù)直接解析成對象，當(dāng)然前提是定義出相應(yīng)的Model，這樣客戶端各層就能用這個(gè)Model了。
可是這里有個(gè)很大的局限性，大家可能遇到了只是當(dāng)作理所當(dāng)然了。情形如下：
需求（含各界面基本布局，UI基本上按這個(gè)布局設(shè)計(jì)）已出，但服務(wù)器接口未給出定義（服務(wù)器所有接口及數(shù)據(jù)已準(zhǔn)備好只等客戶端開發(fā)的可能性幾乎為0），而且很可能服務(wù)器還沒人呢。客戶端能做的工作有哪些呢：
1、界面實(shí)現(xiàn)，StoryBoard或XIB或代碼實(shí)現(xiàn)
2、界面數(shù)據(jù)直接寫在StoryBoard或XIB上，或代碼里隨便寫點(diǎn)數(shù)據(jù)
3、其他
4、UI給切圖了隨時(shí)貼圖
遇到的問題是：
1、服務(wù)器沒給接口格式，沒法定義Model
2、沒Model，測試數(shù)據(jù)只能直接寫在界面上
3、沒服務(wù)器，客戶端無法測試
4、服務(wù)器給了數(shù)據(jù)格式，客戶端開發(fā)完畢后，跟服務(wù)器接口對接才發(fā)現(xiàn)，服務(wù)器并沒完全按先前給的數(shù)據(jù)格式開發(fā)?；蛘叻?wù)器感覺之前寫的數(shù)據(jù)格式不合理，又想改格式，直接導(dǎo)致客戶端改動較大（服務(wù)器寫接口的和寫數(shù)據(jù)庫的往往不是一個(gè)人）——Model得改，界面、數(shù)據(jù)存儲等用到Model的地方都得改
總之，客戶端開發(fā)嚴(yán)重依賴服務(wù)器，項(xiàng)目進(jìn)度嚴(yán)重依賴服務(wù)器
解決辦法：需求已經(jīng)出了，界面布局也出了，界面就可以實(shí)現(xiàn)了，這個(gè)沒什么疑問。重要的是：
1、Model也可以定義了，客戶端定義自己的Model就好了，管他服務(wù)器怎么定義呢，后期可以將服務(wù)器Model轉(zhuǎn)為客戶端Model呀（格式差異較大的話需要靈活處理）。
2、可以給Model定義一個(gè)方法用于生成測試數(shù)據(jù)以供界面顯示這些數(shù)據(jù)（假裝這些數(shù)據(jù)是服務(wù)器給的，^_^）（可以用rand()方法隨機(jī)從幾種數(shù)據(jù)中選，圖片url可以從網(wǎng)上弄貼這里）。
3、客戶端Model有了數(shù)據(jù)，所有工作都能進(jìn)行了。
4、服務(wù)器數(shù)據(jù)格式和url給定后，能一一對應(yīng)上的數(shù)據(jù)用JSONModel提供的辦法解決，不太對應(yīng)上的，可以把服務(wù)器給的數(shù)據(jù)解析成.m文件中類的extension的屬性，然后覆蓋.h中屬性的get方法實(shí)現(xiàn)（Model的頭文件中的屬性是給客戶端其他模塊用的，.m文件中的屬性算是Model的私有屬性了，可以進(jìn)行各種轉(zhuǎn)換）。這一步就實(shí)現(xiàn)了服務(wù)器Model到客戶端Model的轉(zhuǎn)換，只修改Model部分就可以了，不需要修改界面、數(shù)據(jù)存儲等其他模塊的代碼。
服務(wù)器Model轉(zhuǎn)客戶端Model，一般情況一下都比較容易處理，JSONModel本身就支持，另外一些特殊的，比如下面的情況：
1、iPhone界面，上面是一張大圖，下面是列表，所以客戶端定義的Model是倆屬性，一個(gè)大圖的對象數(shù)據(jù)，另一個(gè)是對應(yīng)列表的數(shù)組數(shù)據(jù)。結(jié)果服務(wù)器只給了一個(gè)列表，列表第一個(gè)元素就是那個(gè)大圖數(shù)據(jù)，剩下的是列表。
Model頭文件中的屬性是給客戶端用的，即倆屬性。extension中只定義一個(gè)數(shù)組屬性用于接收服務(wù)器數(shù)據(jù)。然后Model實(shí)現(xiàn)中覆蓋頭文件中屬性的get方法（其實(shí)一般情況下，頭文件中的屬性定義為readonly即可，其他模塊一般不需要修改屬性）。頭文件中的大圖對象返回extension數(shù)組屬性的第一個(gè)元素，頭文件中的數(shù)組屬性返回extension數(shù)組屬性中除去第一個(gè)元素后的其他元素即可。
2、客戶端界面上定義了三張圖片，放在一起滾動顯示，其中第一張圖片是視頻截圖，就像AppStore中的app視頻和截圖那樣。客戶端Model定義為一個(gè)對象數(shù)據(jù)，其中有字段標(biāo)識是視頻還是圖片。結(jié)果服務(wù)器給了倆列表，一個(gè)是視頻列表，一個(gè)是圖片列表。
也很簡單，依然是在.m中覆蓋頭文件中屬性的get方法，將倆服務(wù)器Model的倆數(shù)組合并即可。
總之，客戶端開發(fā)架構(gòu)的思想，就是測試數(shù)據(jù)只集中在一個(gè)地方，而不是把測試數(shù)據(jù)直接寫在界面上。需求定義出來后客戶端首先要做的是架構(gòu)，將數(shù)據(jù)寫在Model里（或者更進(jìn)一步，網(wǎng)絡(luò)請求后設(shè)置Model的測試數(shù)據(jù)。網(wǎng)絡(luò)請求可以暫時(shí)請求百度首頁呀，服務(wù)器給了地址后改成相應(yīng)的url就好了），界面、數(shù)據(jù)存儲等模塊的工作就能全面展開了。而不是簡單的照著需求做界面，然后干等服務(wù)器給數(shù)據(jù)。前期不會太緊，后面也比較輕松，后期只Model跟服務(wù)器對數(shù)據(jù)就可以了。
這些，算得上是比較好的項(xiàng)目解決方案吧。
