Spring Boot歌曲查询服务职责拆分与数据传递方案探讨

业务背景 #

我们要基于歌曲数据库搭建一套支持多类型查询的业务流程，通用执行步骤如下（以Spring Boot为例，逻辑可通用）：

• 通过工厂类匹配查询类型（如摇滚、流行、民谣）
• 解析输入数据，生成对应查询语句
• 调用Repository执行查询，返回List<SongItem>
• 转换生成上层所需的DTO

由于步骤2（解析+生成查询）、步骤4（DTO转换）存在多实现，我们定义了Query接口，包含parse()、createQuery()、prepareAnswer()方法，并针对不同查询类型实现了RockQuery、PopQuery、FolkQuery等具体类。现在需要明确Service层的架构组织方式，以及List<SongItem>在各步骤间的传递逻辑，下面对现有三类思路逐一分析：

思路1：Service主导流程，数据显式传递 #

实现逻辑 #

1. Service层注入SongRepository
2. 通过工厂获取对应Query实例
3. 调用Query.parse()解析输入，再调用Query.createQuery()生成查询语句
4. Service直接调用SongRepository执行查询，得到List<SongItem>
5. 将List<SongItem>传入Query.prepareAnswer()生成最终DTO

优缺点 #

• 优势：职责划分清晰，Service掌控核心流程，Query类只专注于查询语句生成和DTO转换，不依赖Repository，完全符合单一职责原则；List<SongItem>的流转全程可见，调试和问题定位都很方便。
• 劣势：Service层代码会稍显繁琐，需要手动串联Query方法与Repository调用；新增查询类型时，虽然Service逻辑不用修改，但每次都要重复执行这几步，代码冗余度略高。

思路2：Query类封装全流程，内部持有数据 #

实现逻辑 #

1. 每个具体Query类（如RockQuery）内部注入SongRepository
2. 新增performQuery()方法，内部依次执行parse()、createQuery()、调用Repository查询的逻辑，将List<SongItem>作为类成员变量保存
3. Service层只需获取Query实例，先调用performQuery()完成查询，再调用prepareAnswer()生成DTO（直接使用内部持有的数据）

优缺点 #

• 优势：Service层代码极度简洁，只需要调用两个方法就能完成全流程；查询逻辑完全封装在Query类内部，高内聚，新增查询类型时Service层无需修改，符合开闭原则。
• 劣势：Query类职责过重，同时承担了查询生成、执行、DTO转换的工作，违反单一职责；List<SongItem>作为成员变量持有，会导致Query实例无法复用（线程不安全），每次查询都要新建实例，增加对象创建开销；数据流转不透明，调试时需要深入Query内部才能追踪数据来源。

思路3：变体优化方案 #

方案A：引入QueryExecutor解耦依赖 #

新增QueryExecutor组件，注入SongRepository，专门负责接收Query生成的查询语句并执行，返回List<SongItem>。

• Service层流程：获取Query实例 → 解析输入+生成查询 → 调用QueryExecutor执行得到数据 → 传入Query.prepareAnswer()生成DTO
• 优势：既避免了思路1中Service直接依赖Repository的耦合，又不让Query依赖Repository；QueryExecutor可以统一处理分页、权限校验等通用查询逻辑，复用性更强；数据流转依然保持透明。

方案B：用QueryContext封装全上下文 #

定义QueryContext类，包含输入参数、查询语句、List<SongItem>、DTO结果等字段，Query的所有方法都接收并返回这个上下文对象。

• Service层流程：初始化QueryContext并传入输入参数 → 调用Query.parse()更新上下文 → 调用Query.createQuery()更新上下文 → 调用Repository执行查询并更新上下文的List<SongItem> → 调用Query.prepareAnswer()生成DTO并存入上下文 → 从上下文取出DTO返回
• 优势：数据流转完全通过上下文对象传递，避免了多参数传递的繁琐；所有状态都集中在QueryContext中，后续扩展查询日志、性能监控等功能时，直接在上下文加字段即可；Query类依然保持单一职责，只负责上下文的转换处理。

选型建议 #

• 如果团队更看重职责清晰、可调试性，优先选择思路1或变体方案A；
• 如果追求Service层极简、高内聚的查询组件，可以考虑思路2，但必须注意线程安全问题（比如每次查询都新建Query实例）；
• 如果业务复杂度较高，后续可能需要扩展更多上下文信息，变体方案B会是更灵活的选择。

内容的提问来源于stack exchange，提问作者thahgr