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），而且很可能服务器还没人呢。客户端能做的工作有哪些呢：

        1、界面实现，StoryBoard或XIB或代码实现

        2、界面数据直接写在StoryBoard或XIB上，或代码里随便写点数据

        3、其他

        4、UI给切图了随时贴图

        遇到的问题是：

        1、服务器没给接口格式，没法定义Model

        2、没Model，测试数据只能直接写在界面上

        3、没服务器，客户端无法测试

        4、服务器给了数据格式，客户端开发完毕后，跟服务器接口对接才发现，服务器并没完全按先前给的数据格式开发。或者服务器感觉之前写的数据格式不合理，又想改格式，直接导致客户端改动较大（服务器写接口的和写数据库的往往不是一个人）——Model得改，界面、数据存储等用到Model的地方都得改

        总之，客户端开发严重依赖服务器，项目进度严重依赖服务器

        解决办法：需求已经出了，界面布局也出了，界面就可以实现了，这个没什么疑问。重要的是：

        1、Model也可以定义了，客户端定义自己的Model就好了，管他服务器怎么定义呢，后期可以将服务器Model转为客户端Model呀（格式差异较大的话需要灵活处理）。

        2、可以给Model定义一个方法用于生成测试数据以供界面显示这些数据（假装这些数据是服务器给的，^_^）（可以用rand()方法随机从几种数据中选，图片url可以从网上弄贴这里）。

        3、客户端Model有了数据，所有工作都能进行了。

        4、服务器数据格式和url给定后，能一一对应上的数据用JSONModel提供的办法解决，不太对应上的，可以把服务器给的数据解析成.m文件中类的extension的属性，然后覆盖.h中属性的get方法实现（Model的头文件中的属性是给客户端其他模块用的，.m文件中的属性算是Model的私有属性了，可以进行各种转换）。这一步就实现了服务器Model到客户端Model的转换，只修改Model部分就可以了，不需要修改界面、数据存储等其他模块的代码。

        服务器Model转客户端Model，一般情况一下都比较容易处理，JSONModel本身就支持，另外一些特殊的，比如下面的情况：

        1、iPhone界面，上面是一张大图，下面是列表，所以客户端定义的Model是俩属性，一个大图的对象数据，另一个是对应列表的数组数据。结果服务器只给了一个列表，列表第一个元素就是那个大图数据，剩下的是列表。

        Model头文件中的属性是给客户端用的，即俩属性。extension中只定义一个数组属性用于接收服务器数据。然后Model实现中覆盖头文件中属性的get方法（其实一般情况下，头文件中的属性定义为readonly即可，其他模块一般不需要修改属性）。头文件中的大图对象返回extension数组属性的第一个元素，头文件中的数组属性返回extension数组属性中除去第一个元素后的其他元素即可。

        2、客户端界面上定义了三张图片，放在一起滚动显示，其中第一张图片是视频截图，就像AppStore中的app视频和截图那样。客户端Model定义为一个对象数据，其中有字段标识是视频还是图片。结果服务器给了俩列表，一个是视频列表，一个是图片列表。

        也很简单，依然是在.m中覆盖头文件中属性的get方法，将俩服务器Model的俩数组合并即可。

        总之，客户端开发架构的思想，就是测试数据只集中在一个地方，而不是把测试数据直接写在界面上。需求定义出来后客户端首先要做的是架构，将数据写在Model里（或者更进一步，网络请求后设置Model的测试数据。网络请求可以暂时请求百度首页呀，服务器给了地址后改成相应的url就好了），界面、数据存储等模块的工作就能全面展开了。而不是简单的照着需求做界面，然后干等服务器给数据。前期不会太紧，后面也比较轻松，后期只Model跟服务器对数据就可以了。

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