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跟服务器对数据就能够了。

        这些，算上得是比较好的项目设计方案吧。