Как правильно организовать запросы Knex?

Question

Я попал в ловушку «так много папок», и мне очень сложно отслеживать все мои запросы Knex в папке контроллеров. Просто, чтобы дать вам идею - у меня более 140 различных js-файлов только с запросами.

Вот пример из моей папки КОНТРОЛЛЕРЫ, чтобы дать вам представление о том, как неаккуратно это:

• запросов
• стандартные
  • getOpenProjects.js
  • getClosedProjects.js
  • createNewProjects.js
  • getProjectsChart .js
  • getClosedProjectsChart.js
  • ... (еще 41 файл)
• графики
  • lineChartOfTechs.js
  • delayedTechs.js
  • overallPie.js
  • ... (более 11 файлов)
• задачи
  • getTasksByTech.js
  • delayedTasks.js
  • tasksColumnTask.js
  • . .. (35 больше файлов)

Как вы можете видеть, я пытался держать его в папках, но, как я закодированы вместе - я просто назвал его в файлы для справки. Он получает утомительный поиск по каждой папке для точного файла, который мне нужен.

Я попытался использовать Книжную полку JS, но есть так много сложных левых соединений - я в конце концов сдался и вернулся к KnexJS. Некоторые из ответов на канал «Книжная полка» в конечном итоге сказали мне использовать команду «Книжная полка» Knex RAW. Я подумал, что если я вернусь к Кнексу, я мог бы придерживаться его, а не добавлять еще один модуль.

В любом случае - вопрос в том, как правильно структурировать, чтобы я мог легко найти то, что искал? Как вы это сделаете в своем проекте? Есть ли хороший инструмент организации для сохранения запросов или кода Knex?

Answer 1

Мы используем objection.js на вершине knex как ОРМ (возражение использует knex в качестве конструктора запросов и миграции) и в основном пишут наши запросы непосредственно в контроллерах (я знаю, некоторые люди, считает это еретик).

Поскольку большинство запросов используются только один раз, нет необходимости обертывать каждого из них какой-либо отдельной функцией. Он просто делает рефакторинг и сменяет код сложнее, и может закончиться плохо названной функцией запроса, если какое-то позднее изменение изменит значение запроса, но имя функции не фиксировано и т. Д.

Так что для простых и разовых запросов мы делаем это прямо :

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

Если есть сложный запрос, который необходим в нескольких местах, мы пишем его в качестве метода для соответствующего класса модели.

Например, если запрос возвращает Person модели, запрос будет записан в класс Person. Конечно, будут исключения из этих базовых правил, но можно отдельно рассмотреть все те случаи, что с ними делать.

В нашем текущем проекте у нас около 40 моделей, и мы не испытывали никаких проблем при попытке выяснить, как организовать наши запросы.