如何正确组织Knex查询？

Question

我陷入了“这么多文件夹”陷阱，我发现很难跟踪控制器文件夹中的所有Knex查询。只是为了给你一个想法 - 我只有140个不同的js文件只有查询。

这是我的CONTROLLERS文件夹的示例，可以让您了解它是多么混乱：

• 查询
• 标准
  • getOpenProjects.js
  • getClosedProjects.js
  • createNewProjects.js
  • getProjectsChart.js
  • getClosedProjectsChart.js
  • ...（另外41个文件）
• charts
  • lineChartOfTechs.js
  • delayedTechs.js
  • overallPie.js
  • ...（另外11个档案）
• 任务
  • getTasksByTech.js
  • delayedTasks.js
  • tasksColumnTask.js
  • ...（35更多文件）

正如你所看到的，我试过将它保存在文件夹中，但是当我编码时 - 我只是把它命名为文件以供参考。在每个文件夹中搜索我需要的确切文件都很累。

我尝试使用Bookshelf JS但是有很多复杂的左连接 - 我最终放弃了并回到了KnexJS。 Bookshelf频道的一些答案最终告诉我使用Bookshelf Knex RAW命令。我想 - 如果我要回Knex - 我不妨坚持下去而不是添加另一个模块。

无论如何 - 问题是 - 我如何正确地构建这个，以便我可以轻松找到我正在寻找的东西？你会如何在你的项目中做到这一点？是否有任何好的组织工具来保存查询或Knex代码？

Answer 1

我们在knex之上使用objection.js作为ORM（异议使用knex作为其查询构建器和迁移）并且主要在我们的控制器中直接编写查询（我知道，有些人认为这是作为异教徒）。

由于大多数查询只使用过一次，因此将其中的每个查询都包含在一些单独的函数中是没有用的。它只是使重构和更改代码变得更加困难，如果稍后更改修改查询含义，但最终可能会出现命名错误的查询函数，但函数名称不固定等。

因此，对于简单和一次性查询，我们直接执行此操作：

let person = await Person.query().findById(personId);

如果在多个地方需要一些复杂的查询，我们将其作为一个方法写入相应的Model类。

例如，如果查询返回Person模型，则查询将写入Person类。当然这些基本规则会有例外，但是可以单独考虑所有这些情况如何处理它们。

在我们目前的项目中，我们有大约40个模型，并且在尝试找出如何组织查询时没有遇到任何问题。

编辑：

我确实错过了原始答案中的案例，其中我们有对多个表执行多个查询的方法。

通常我们将它们包装到一个单独的服务API类中，该类明确说明它为应用程序提供的功能，并将API注入需要它的控制器。