Куда относится сложная логика приложения в модели MVC? - PullRequest
Новая
       29

Куда относится сложная логика приложения в модели MVC?

2 голосов
/ 25 июня 2019

Итак, у меня есть экспресс-приложение.Я использую модель MVC, у меня есть Sequelize для слоя Model, Handlebars for View и Express для Controller.

Мое приложение выполняет некоторые тривиальные манипуляции с БД, я достигаю этого, расширяя функции Sequelize и максимально используя модель.изнутри Контроллера.

Тем не менее, у меня есть некоторые более сложные задачи, которые:

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

Где я могу разместить этот код в соответствии с соглашением для обеспечения читабельности?

  • Я не могу поместить его в models/ папка, это не Sequelize Model класс
  • Я не могу держать его в коде контроллера, это снижает возможность повторного использования этого кода и раздувает мои контроллеры
  • Я не могу поместить его в отдельныйфайл внутри папки controllers/, поскольку он не является экспресс-совместимой функцией, поэтому не является контроллером как таковым.

У меня есть папка utils/, но этоЭмс, как ленивый выбор.В итоге я получу случайные функции, для которых у меня нет лучшего места в одном месте.

Где вы, ребята и девчонки, размещаете такой код в своих приложениях (код, который работает с моделями, но не является частью единого кода)?)?

РЕДАКТИРОВАТЬ

Я получил 

db/
---models/
---interactors/
------invoicing/
------user-manipulation/
...

структуру

1 Ответ

1 голос
/ 25 июня 2019

Мой опыт показывает, что у вас будет уровень обслуживания или уровень бизнес-логики .

Вы можете структурировать его очевидным образом, если у вас есть отдельные папки для controllers, services, models и т. Д. Или создать модульную или компонентную структуру, сгруппированную по типу модель / API, где users будет включать пользовательские файлы. При работе с несколькими моделями сервисы могут зависеть от других сервисов и контроллеров может зависеть от нескольких сервисов, но убедитесь, что у контроллера нет бизнес-логики.

Обратите внимание на ссылку, где написано:

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

Для приложения MVC это подразумевает как минимум четыре слоя. Модели, представления, контроллеры и сервисы; это довольно часто можно увидеть. Но также может быть полезным вытащить доступ к БД на свой собственный уровень. Таким образом, вы не привязаны к определенному типу хранилища, поставщику или структуре, и это помогает в тестировании. Это будет, где использование ORM будет, например, и используется службами.

...