84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
周日的沙龙,gosboy大哥提到了,移动应用服务器端API需要根据版本号、平台的不同物理的分离,是为了在某个版本出现问题的时候方便统计和针对性的修改(还有其他好处么?)。我想这样子是不是好多代码冗余了,那如果有个问题,很多地方都需要修改,不是要同时修改多个文件了么?
人生最曼妙的风景,竟是内心的淡定与从容!
我来回答,我来回答 首先好处: 1,版本之间互不依赖。数据,配置信息,统计,等等都可以针对版本订制。往往新版发布以后,旧版本接口将不再运营,取而代之的都是更新提示等,这样就要求多版本的数据各不相同。 2,代码清晰。版本多了以后,难免出现各种判断,如果物理分离,就不需要了,各种清晰 3,我还没想到 然后代码冗余的问题: 首先,代码物理分离,但逻辑可以不分离。就是说,你要有一个BaseAPI基本满足需求,或者说可以满足1.0版本全部需求。 然后,版本API继承这个BaseAPI,最基本的版本API就是一堆继承自BaseAPI的空壳,只有当有个性化需求的时候,才去重写某些接口(方法)。 最重要的一点:版本之间一定是可继承的。也就是说,1.0继承自Base,2.0一般如果变化不大,就继承自1.0。 最后举一个较复杂的例子: 1.0继承自Base,Base是可以满足1.0全部需求的,1.0接口只是重写了版本检测等版本号以来的方法。 2.0发布,添加了一个只有2.0才支持的新功能,仅此而已。2.0接口也继承自Base,但新功能是卸载2.0里的。 2.0.1发布,修正了一些Bug。2.0.1的接口就继承自2.0接口。 3.0发布,对全部版本数据有一些较大的更新,另新增一个功能。把全部版本的更新写进Base,3.0接口继承自2.0.1,新增功能在3.0中实现
物理分离倒是不必要,冗余也有缺点的.但是版本控制是必须的. 只要能能快速的切换/回滚版本,应该就可以满足需要了. 版本镜像可以作为一个辅助手段 另外: 最好能实现版本的升降级脚本,这样子就更好了
我来回答,我来回答
首先好处:
1,版本之间互不依赖。数据,配置信息,统计,等等都可以针对版本订制。往往新版发布以后,旧版本接口将不再运营,取而代之的都是更新提示等,这样就要求多版本的数据各不相同。
2,代码清晰。版本多了以后,难免出现各种判断,如果物理分离,就不需要了,各种清晰
3,我还没想到
然后代码冗余的问题:
首先,代码物理分离,但逻辑可以不分离。就是说,你要有一个BaseAPI基本满足需求,或者说可以满足1.0版本全部需求。
然后,版本API继承这个BaseAPI,最基本的版本API就是一堆继承自BaseAPI的空壳,只有当有个性化需求的时候,才去重写某些接口(方法)。
最重要的一点:版本之间一定是可继承的。也就是说,1.0继承自Base,2.0一般如果变化不大,就继承自1.0。
最后举一个较复杂的例子:
1.0继承自Base,Base是可以满足1.0全部需求的,1.0接口只是重写了版本检测等版本号以来的方法。
2.0发布,添加了一个只有2.0才支持的新功能,仅此而已。2.0接口也继承自Base,但新功能是卸载2.0里的。
2.0.1发布,修正了一些Bug。2.0.1的接口就继承自2.0接口。
3.0发布,对全部版本数据有一些较大的更新,另新增一个功能。把全部版本的更新写进Base,3.0接口继承自2.0.1,新增功能在3.0中实现
物理分离倒是不必要,冗余也有缺点的.但是版本控制是必须的.
只要能能快速的切换/回滚版本,应该就可以满足需要了.
版本镜像可以作为一个辅助手段
另外:
最好能实现版本的升降级脚本,这样子就更好了