在 TypeORM 中使用 QueryBuilder 与 Repository 都有哪些不同的用例？ [关闭]

Posted 2023-03-10

【中文标题】在 TypeORM 中使用 QueryBuilder 与 Repository 都有哪些不同的用例？ [关闭]

【英文标题】：What are the different use cases for using QueryBuilder vs. Repository in TypeORM? [closed]在 TypeORM 中使用 QueryBuilder 与 Repository 有哪些不同的用例？ [关闭]

【发布时间】：2020-03-02 11:13:58

【问题描述】：

我正在使用带有 TypeORM 的 NestJS 构建一个 API。我一直在使用 TypeORM Repository API 查询 mysql 数据库，主要是因为 NestJS Database documentation section 提供了一个使用 this.photoRepository.find() 的示例。随着我的深入，我注意到我的许多探索性搜索结果出于性能和灵活性的原因推荐使用 TypeORM QueryBuilder API。

如果我决定切换我的数据库框架，我会感觉到存储库方法更易于满足简单需求和出色的抽象。另一方面，在我看来，QueryBuilder 的性能和可定制性也更高。

我们能否概述一下 TypeORM 中 QueryBuilder 与 Repository 的不同用例？

【问题讨论】：

@AndreFeijo 我更新了标题和问题，用事实和引文而不是意见来回答。我们可以重新开放吗？

【参考方案1】：

QueryBuilder API 比 Repository API 更强大且更接近 SQL，因此任何更复杂或更受 SQL 驱动的事情都可以通过它更轻松地完成。这是您在使用 QueryRunner 使用原始 SQL 之前的最后一个“工具”，您可能不想每次都使用它（因为它会使开发和重构时间更长）。

即使存储库更容易实现，也许您不希望您的代码库允许使用 2 API，因为它会“拆分”代码，但这完全取决于您的团队偏好。

存储库 API 更友好的一点是获取关系，因为从装饰器中解析了急切/惰性关系，并且您不必指定“连接”，而 QueryBuilder 暗示您明确表示这些关系，否则它只会获取主表（它忽略装饰器，SQL 是第一公民）。

无论如何，即使您决定放弃 Repository API 或 QueryBuilder API，我强烈建议您始终在专用类（如自定义存储库或专用服务）中轻松找到您的查询，以免您最终在代码库的任何地方维护查询，如果不加以控制，重构数据访问是危险的。例如，我个人发现 Repository API 上的“查找”方法过于强大，并且不允许在专用服务/类/您决定的任何内容之外使用此类 API。