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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 195,980评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,422评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,130评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,553评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,408评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,326评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,720评论 3 386
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,373评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,678评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,722评论 2 312
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,486评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,335评论 3 313
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,738评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,009评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,283评论 1 251
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,692评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,893评论 2 335

推荐阅读更多精彩内容