聚合搜索优化

问题：怎样能让前端一次搜出所有数据、又能分别获取某一类数据（比如分页场景）

解决方案：

新增 type 字段：前端传 type 调用后后端同一个接口，后端根据 type 不同调用不同的 service 查询

比如前端传递 type = post ，后端执行 postService.query

逻辑：

1. 如果 type 为空，那么搜索出所有数据
2. 如果 通哟额 不为空
   1. 如果 type 合法，查出对应数据
   2. 否则报错

存在的问题： type 增多后，要把查询逻辑堆积在 controller 代码里吗？

思考：如何让搜索系统 更有效地接入更多的数据源？

门面模式

介绍：帮助我们用户（客户端）更轻松地实现功能，不需要关注门面背后的细节

聚合搜索业务基本都是门面模式，即前端不同关心后端从哪里来、怎么去取不同来源、怎么去聚合不同来源的数据，更方便地获取到内容。

当调用系统（接口）的客户端觉得麻烦时，需要考虑是否可以抽象一个门面。

适配器模式

1）定制统一的数据源接入规范（标准）：

• 什么数据源允许接入？
• 数据源接入的时候需要满足什么条件
• 需要接入方的注意事项

聚合搜索系统要求：任何接入系统的数据，都必须能够根据关键词搜索、并且支持分页搜索

通过声明接口的方式来定义规范。

2）如果数据源已经支持了搜素，但是原有的方法参数和我们规范的不一致，如何解决？

使用适配器模式：通过转换，让两个系统能够完成对接。

注册器模式

提前通过一个 map 或者其他类型存储好后面需要调用的对象。

效果：替换了 if … else …, 代码量大幅度减少，可维护可扩展。

搜索优化

现有问题：搜索不灵活

比如搜 ”墨枫rapper“ 无法搜索到 ”墨枫是rapper“ 因为 MySQL 数据库的 like 是包含查询。