在TypeORM中，DAO的实体列表与查询搜索方法该分离还是合并？

背景 #

我是一名使用Node.js+TypeScript+TypeORM的后端开发者，目前在设计TPA实体的Repository/DAO层时遇到抉择：现有两个服务于不同API的独立方法，纠结是保留独立方法还是合并为带配置选项的单一方法。

当前的两个独立方法 #

1. getAll()

用于TPA管理界面，支持分页过滤，返回包含软删除数据的全量信息：

async getAll(
    companyId: string,
    page: number,
    limit: number,
    filters?: {
        // 包含多个过滤字段
    },
): Promise<{ data: TPA[]; total: number }>

2. getTPAInfo()

用于用户创建关联TPA的记录时快速查询，返回未删除的活跃TPA的轻量数据（仅id和name）：

async getTPAInfo(
    companyId: string,
    query: string,
): Promise<{ id: string; name: string; }[]>

可选方案 #

选项A：保留独立方法 #

理由：两个方法对应完全不同的业务用例，返回数据结构、过滤规则差异明显，分开实现更清晰。

选项B：合并为单一方法 #

通过配置选项控制行为，合并为一个API方法，示例：

async getAll(
    companyId: string,
    filters?: {
        // 包含多个过滤字段
    },
    options?: {
        includeDeleted?: boolean;
        onlyActive?: boolean;
        lightweight?: boolean;
        search?: string;
    }
)

方案分析与推荐 #

优先选选项A（保留独立方法），原因如下： #

• 职责单一：每个方法只对应一个明确的业务场景，代码逻辑聚焦，后续维护时不用在庞杂的分支逻辑里排查问题。
• 类型安全清晰：TypeScript能精准约束输入输出，比如getTPAInfo固定返回{id: string; name: string}数组，调用方无需额外处理返回字段的不确定性。
• 性能优化针对性强：getTPAInfo仅需查询id和name，还能直接过滤软删除数据，可以写出更高效的SQL（仅选必要字段、添加活跃状态过滤）；合并后的方法需要大量条件判断拼接查询，容易产生性能冗余。
• API语义明确：调用方看到getAll就知道是拿全量分页数据，看到getTPAInfo就知道是拿轻量关联数据，无需记忆一堆配置选项的含义。

考虑选项B的场景 #

如果后续出现5个以上逻辑高度重叠的查询需求（仅过滤/返回字段略有差异），可以抽象基础查询逻辑，用选项控制变体避免代码重复。但就当前两个明确区分的场景而言，选项A的收益更高。

内容的提问来源于stack exchange，提问作者Saif AD Abbas