我正在使用带有TypeORM的nestJS构建API。我一直在使用TypeORM Repository API查询MySQL数据库，主要是因为NestJS Database documentation section提供了一个使用this.photoRepository.find()的示例。随着时间的流逝，我发现许多探索性搜索结果都建议出于性能和灵活性的原因而使用TypeORM QueryBuilder API。
我已经感觉到，如果我决定切换数据库框架，则可以轻松地将Repository方法用于简单的需求和更好的抽象。另一方面，在我看来QueryBuilder的性能和可定制性也更高。
我们能否概述TypeORM中QueryBuilder与存储库的不同用例？
QueryBuilder API非常强大，并且比Repository API更接近SQL，因此，任何更复杂或更多SQL驱动的事情都可以通过它轻松完成。这是您使用QueryRunner进行原始SQL之前的最后一个“工具”，您可能不想每次都使用它（因为它会使开发和重构的时间更长）。
即使该存储库更容易实现，也许您也不希望您的代码库允许使用2 API，因为它会“拆分”代码，但这完全取决于您的团队偏好。
存储库API更友好的一点是关于获取关系，因为从装饰器中解析了急切/懒惰的关系，而您不必指定“ joins”，而QueryBuilder则暗示您显式的那些关系，否则它将仅获取主表（它忽略装饰器，SQL是第一个公民）。
无论如何，即使您决定放弃Repository API或QueryBuilder API，我也强烈建议您始终在专用类（如自定义存储库或专用服务）中轻松找到您的查询，以免最终失败在代码库中的所有地方维护查询，如果不加以控制，重构数据访问将很危险。我个人认为“查找”方法在存储库API上过于强大，例如，并禁止在专用服务/类/您决定的范围之外使用此类API。