[发明专利]一种搜索方法、装置及存储介质

说明书

本发明公开了一种搜索方法、装置及存储介质，所述方法包括：将搜索得到的原始数据通过第一转换装置转换为与触发搜索操作的业务相适配的数据模型；将转换得到的所述数据模型通过第二转换装置转换为视图对象，并将页面跳转至所述视图对象对应的搜索结果页面。本发明所述方案，实现了搜索页面的组件化，提高了搜索页面的复用性，减少了代码冗余。

技术领域

本发明涉及计算机领域，尤其涉及一种搜索方法、装置及存储介质。

背景技术

目前，很多APP(计算机应用程序)均可实现内部搜索，例如，58同城APP，具体的，58同城APP首页提供搜索功能，称为全站搜；58同城APP还有二手物品、房产、二手车、招聘、黄页等几大业务线，这是粗粒度的业务线，细分一下，二手可以拆分出二手物品、宠物等类别；房产拆分出租房、二手房等类别；招聘拆分出全职招聘、兼职等类别；黄页拆分出家政、本地服务等类别。拆分出的这些较细的类别的页面称之为大类页，这些大类页也提供搜索功能，称为大类搜。其中，大类页提供更细粒度的类别，如进入二手房大类页后会看到二手房、新房、商铺、厂房等入口，再次进入后是列表页，这些列表页也提供搜索功能，称为列表搜。

如图1所示，为目前APP实现内部搜索常用的搜索框架图。虽然看上去比较清晰，但是实际存在着很多问题，比如代码冗余、耦合度高、不易复用等。这些问题也是一些大型模块经过多次升级，到了后期经常存在的问题。接下来就具体问题进行具体分析。

随着业务的扩展，各APP的业务线也在逐渐成型和完善。每个业务线的大类页接入搜索功能也存在先后。业务线内部的列表页，更是多种多样，以58同城APP为例，业务线内部的列表页包括Native(原生)的类别页、Web列表页，还有特殊的列表页如简历库列表页、地图搜房页等等，这些列表页后来也都一一实现了搜索功能。不过也正是因为实现的时间有先后，逐渐积累产生了一些历史遗留问题。具体的：

(1)代码冗余问题：

不同的业务页面对搜索功能的支持有先后之别，后实现搜索的页面都是先拷贝一份先实现搜索页面的代码，然后把其中的业务代码删除，加入本业务页面的业务代码。这样，业务入口页面就各自实现了自己的一套搜索逻辑，如图2所示，这样会导致重复的代码超过10000行。

(2)耦合度高问题：

从图1可以看出，搜索页面是由业务入口页面管理和加载的。搜索页面要处理数据，包括热词和搜索历史的本地获取及服务器获取。搜索页面要处理网络请求，包括关键词的联想请求、关键词的搜索请求。进一步地，搜索页面还要实现视图的协议方法。这些大量的逻辑都是在业务页面文件中实现的。

在代码管理上，尽管已经把搜索相关的代码剥离出来，单独放到了一个Category类别文件中，但是实际上还是无法避免地跟业务页面逻辑耦合在一起。例如：

1、文件级别。业务页面文件中，既有业务方法，又有搜索相关的方法；

2、方法级别。在同一个方法中，既有业务逻辑，又有搜索逻辑。这是更为严重的耦合。

(3)搜索页面无法复用问题：

因为搜索页面与业务页面耦合度高，所以业务入口页面无法复用以前的搜索页面，只能各自实现。相反的，越来越多的业务入口页面不再考虑搜索页面的复用性，只考虑自己独自实现，导致搜索页面越来越多，比以前更加难以复用和移植。

另一个无法复用的原因来自于搜索页面自身的定制化严重。搜索页面需要清楚知道是否存在热词、搜索历史、联想结果等，然后来定制显示视图，如图3所示，是两个搜索页面的简化类图。搜索页面的列表协议方法均直接访问了搜索页面的属性，但是其属性是与搜索业务直接相关的。全站搜中没有城市业务，而城市选择页搜页面也没有热词等业务，这样的定制导致搜索页面无法复用。

(4)业务功能接入成本高问题：

业务功能接入成本高，表现在两个方面：