使用Knex.js时将查询结果转换为领域实体的最优方法是什么？

你当前选择的Repository模式是适配该场景的最优基础方案，既保留了Knex手写SQL的灵活可控性，完全规避了ORM黑盒带来的不必要查询复杂度，同时可以将数据访问逻辑和上层业务逻辑完全隔离，GraphQL resolver层完全不需要感知底层存储实现。
在此基础上可以结合以下思路进一步优化实现：

• 解耦转换逻辑和Repository查询逻辑
  如果领域实体数量多、转换逻辑复杂度较高时，可以把纯转换逻辑单独抽离为独立的Data Mapper函数，和Repository的查询代码拆分。每个领域实体对应专属的Mapper函数，示例如下：

// 单独抽离的Mapper逻辑
type UserDbRow = {
  id: number;
  first_name: string;
  last_name: string;
  created_at: string;
}
type UserEntity = {
  id: number;
  fullName: string;
  createdAt: Date;
}
export const toUserEntity = (row: UserDbRow): UserEntity => {
  return {
    id: row.id,
    fullName: `${row.first_name} ${row.last_name}`,
    createdAt: new Date(row.created_at)
  }
}

Repository层只需要在查询完成后调用对应Mapper函数即可，转换逻辑可单独复用、单独编写单元测试，调整转换规则时不需要修改查询相关代码。

• 增加转换层运行时校验
  在转换逻辑中嵌入简单的运行时校验逻辑，确保返回给GraphQL层的实体完全符合领域类型定义，避免数据库脏数据导致上层服务报错。可以选择轻量的校验库实现，也可以手写简单校验逻辑，转换失败时抛出明确的领域错误，方便上层统一处理。
• 用轻量Knex插件减少基础转换代码
  对于下划线转驼峰这类通用基础转换需求，可以用knex-stringcase这类轻量Knex插件全局配置自动处理，不需要手动编写每一个基础字段的映射，减少重复代码，仅需要在Mapper中处理特殊业务字段的转换逻辑即可。
• Repository层对外只返回领域实体
  所有SQL查询逻辑全部封装在Repository内部，对外暴露的接口仅返回领域实体，不返回数据库原始行数据，后续调整底层存储方案时不需要修改上层Resolver的逻辑，业务层完全感知不到存储实现细节。
  以上方案完全符合你选择Knex而非ORM的核心诉求，你可以完全控制每一条SQL的实现，不会出现ORM自动生成的低效查询问题，同时保证了代码的可维护性。

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