在Entity与DTO组装转换的Assembler中使用DAO是否是合理的实现方式？

结论 #

这种实现可以正常运行，但不符合架构设计的单一职责原则，长期来看存在维护隐患，不推荐这么做。 #

存在的问题 #

• 职责越界：Assembler组件的核心定位是DTO和Entity之间的纯属性映射转换，只需要处理字段拷贝、关联关系的绑定即可，不应该耦合数据库查询逻辑。注入DAO后会导致组件职责混杂，后续调整映射规则、修改查询逻辑都需要修改同一个类，维护成本上升。
• 性能与事务风险：Assembler本身是轻量无状态的通用组件，如果内部嵌入DAO查询，很容易在不需要关联Car数据的场景误调用该方法，触发不必要的DB请求；同时如果调用方未开启事务，还可能引发懒加载异常、数据库连接泄漏等问题。
• 单元测试复杂度提升：纯映射的Assembler单测只需要构造DTO、Entity对象直接校验映射结果即可，注入DAO后需要额外Mock DAO的返回结果，测试成本大幅上升。

优化方案 #

方案1（推荐）：查询逻辑上移到业务层 #

将Car的查询逻辑移到调用mergeDtoIntoAggregate的业务Service中，把查询得到的Car映射集合作为参数传入转换方法，修改后方法签名如下：

public User mergeDtoIntoAggregate(UserDto dto, Map<UUID,Car> carMap)

调整后Assembler完全不需要感知DAO的存在，职责纯粹，也方便不同业务场景复用转换逻辑。

方案2：拆分不同职责的转换组件 #

如果你的业务场景中必须在转换阶段自动补全关联实体，可以拆分两类转换组件：

• 纯映射的基础Assembler：只做字段拷贝，无任何外部依赖
• 聚合转换的业务Assembler：依赖DAO和基础Assembler，专门处理需要补全关联实体的特定业务场景

额外优化建议 #

当前UserAssembler中包含了Profile、Role、Order的映射逻辑，建议把这些逻辑抽成独立的Assembler组件注入到UserAssembler中，避免代码冗余，方便后续复用对应实体的转换能力。 #

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