如何正确组织Knex查询

Question

我陷入了"文件夹太多"的陷阱，发现很难在controllers文件夹中跟踪所有Knex查询。只是给你一个想法-我有140多个不同的js文件，只有查询。

下面是我的CONTROLLERS文件夹的一个示例，让你了解它有多乱：

• 查询
• 标准
  • getOpenProjects.js
  • getClosedProjects.js
  • createNewProjects.js
  • 获取项目图表.js
  • 获取已关闭项目图表.js
  • 。。。(还有41个文件)
• charts
  • lineChartOfTechs.js
  • delayedTechs.js
  • overallPie.js
  • 。。。(另外11个文件)
• tasks
  • getTasksByTech.js
  • delayedTasks.js
  • tasks列Task.js
  • 。。。(另外35个文件)

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

我试着使用Bookshelf JS，但有太多复杂的剩余联接——我最终放弃了，回到了KnexJS。Bookshelf频道的一些答案最终告诉我使用Bookshelf Knex RAW命令。我想，如果我要回到Knex，我还不如坚持使用它，而不是添加另一个模块。

无论如何——问题是——我该如何正确地构建它，这样我就可以很容易地找到我想要的东西？你会如何在你的项目中做到这一点？有什么好的组织工具可以保存查询或Knex代码吗？

Answer 1

我们在knex之上使用objection.js作为ORM(objection使用knex作为其查询生成器和迁移)，并且大多数情况下直接在控制器中编写查询(我知道，有些人认为这是异端)。

由于大多数查询只使用过一次，因此没有必要将所有查询打包到某个单独的函数中。这只会使重构和更改代码变得更加困难，如果以后的一些更改修改了查询含义，但函数名称没有固定等，则可能会导致查询函数名称不正确。

因此，对于简单的一次性查询，我们直接这样做：

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

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

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

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

编辑：

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

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