JSONModel對架構的影響及解決方案

        愈來愈多的項目使用CocoaPods，使用CocoaPods頗有可能會用過JSONModel。

        JSONModel是個很強大的庫，只要根據JSON定義好對應的類並繼承JSONModel，就能夠把JSON字符串轉成該對象，並且對數據的轉換還有很強的兼容性，好比跨層解析。以下示例：

        JSON字符串是這樣的：

 

    {
        "articleId":"12314",
        "author":{
            "name":"xiaofang",
            "icon":"http://......"
        }
    }

        類定義是這樣的：

 

 

    @interface ArticleInfo : JSONModel
    @property NSString *articleId;
    @property NSString *authorName;
    @property NSStirng *authorIconUrl;
    @end

        「articleId」解析天然沒問題，「authorName」和「authorIcon」就須要指定解析規則了，以下：

 

 

   + (JSONKeyMapper *)keyMapper
    {
        return [[JSONKeyMapper alloc] initWithDictionary:@{@"author.name": @"authorName", @"author.icon": @"authorIconUrl"}];
    }

        以上能夠看出JSONModel是至關強大的，能夠把服務器給的JSON數據直接解析成對象，固然前提是定義出相應的Model，這樣客戶端各層就能用這個Model了。
        但是這裏有個很大的侷限性，你們可能遇到了只是看成理所固然了。情形以下：

 

        需求（含各界面基本佈局，UI基本上按這個佈局設計）已出，但服務器接口未給出定義（服務器全部接口及數據已準備好只等客戶端開發的可能性幾乎爲0），並且極可能服務器還沒人呢。客戶端能作的工做有哪些呢：

        一、界面實現，StoryBoard或XIB或代碼實現

        二、界面數據直接寫在StoryBoard或XIB上，或代碼裏隨便寫點數據

        三、其餘

        四、UI給切圖了隨時貼圖

        遇到的問題是：

        一、服務器沒給接口格式，無法定義Model

        二、沒Model，測試數據只能直接寫在界面上

        三、沒服務器，客戶端沒法測試

        四、服務器給了數據格式，客戶端開發完畢後，跟服務器接口對接才發現，服務器並沒徹底按先前給的數據格式開發。或者服務器感受以前寫的數據格式不合理，又想改格式，直接致使客戶端改動較大（服務器寫接口的和寫數據庫的每每不是一我的）——Model得改，界面、數據存儲等用到Model的地方都得改

        總之，客戶端開發嚴重依賴服務器，項目進度嚴重依賴服務器

        解決辦法：需求已經出了，界面佈局也出了，界面就能夠實現了，這個沒什麼疑問。重要的是：

        一、Model也能夠定義了，客戶端定義本身的Model就行了，管他服務器怎麼定義呢，後期能夠將服務器Model轉爲客戶端Model呀（格式差別較大的話須要靈活處理）。

        二、能夠給Model定義一個方法用於生成測試數據以供界面顯示這些數據（僞裝這些數據是服務器給的，^_^）（能夠用rand()方法隨機從幾種數據中選，圖片url能夠從網上弄貼這裏）。

        三、客戶端Model有了數據，全部工做都能進行了。

        四、服務器數據格式和url給定後，能一一對應上的數據用JSONModel提供的辦法解決，不太對應上的，能夠把服務器給的數據解析成.m文件中類的extension的屬性，而後覆蓋.h中屬性的get方法實現（Model的頭文件中的屬性是給客戶端其餘模塊用的，.m文件中的屬性算是Model的私有屬性了，能夠進行各類轉換）。這一步就實現了服務器Model到客戶端Model的轉換，只修改Model部分就能夠了，不須要修改界面、數據存儲等其餘模塊的代碼。

        服務器Model轉客戶端Model，通常狀況一下都比較容易處理，JSONModel自己就支持，另一些特殊的，好比下面的狀況：

        一、iPhone界面，上面是一張大圖，下面是列表，因此客戶端定義的Model是倆屬性，一個大圖的對象數據，另外一個是對應列表的數組數據。結果服務器只給了一個列表，列表第一個元素就是那個大圖數據，剩下的是列表。

        Model頭文件中的屬性是給客戶端用的，即倆屬性。extension中只定義一個數組屬性用於接收服務器數據。而後Model實現中覆蓋頭文件中屬性的get方法（其實通常狀況下，頭文件中的屬性定義爲readonly便可，其餘模塊通常不須要修改屬性）。頭文件中的大圖對象返回extension數組屬性的第一個元素，頭文件中的數組屬性返回extension數組屬性中除去第一個元素後的其餘元素便可。

        二、客戶端界面上定義了三張圖片，放在一塊兒滾動顯示，其中第一張圖片是視頻截圖，就像AppStore中的app視頻和截圖那樣。客戶端Model定義爲一個對象數據，其中有字段標識是視頻仍是圖片。結果服務器給了倆列表，一個是視頻列表，一個是圖片列表。

        也很簡單，依然是在.m中覆蓋頭文件中屬性的get方法，將倆服務器Model的倆數組合並便可。

        總之，客戶端開發架構的思想，就是測試數據只集中在一個地方，而不是把測試數據直接寫在界面上。需求定義出來後客戶端首先要作的是架構，將數據寫在Model裏（或者更進一步，網絡請求後設置Model的測試數據。網絡請求能夠暫時請求百度首頁呀，服務器給了地址後改爲相應的url就行了），界面、數據存儲等模塊的工做就能全面展開了。而不是簡單的照着需求作界面，而後乾等服務器給數據。前期不會太緊，後面也比較輕鬆，後期只Model跟服務器對數據就能夠了。

        這些，算上得是比較好的項目設計方案吧。