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

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




原文地址:https://www.cnblogs.com/yjh4866/p/6253941.html