Структурирование контроллеров Laravel

У меня есть

users
    id
    username

companies
    id

areas
    id

area_company
    id
    area_id      
    company_id

area_company_user
    id
    area_company_id      
    user_id

company_user
    id
    company_id
    user_id

area_user
    id
    area_id
    user_id

куда

  • один user имеет от 0 ко многим areas И один area может иметь от 0 ко многим users
  • один area может иметь от 0 до многих companies И один company может иметь от 0 до многих areas
  • один company может иметь от 0 до многих users И один user может иметь от 0 до многих companies
  • один area_company может иметь от 1 ко многим users И один user может иметь от 0 ко многим area_company
  • area_company_user имеет атрибуты, характерные для этого вида user

Кроме того, я структурирую маршруты следующим образом.

  1. /users - все существующие пользователи
  2. /areas - все существующие области
  3. /companies - все существующие компании
  4. /areas/{area}/companies - все существующие компании в определенной области
  5. /users/{user}/companies - все существующие компании от конкретного пользователя
  6. /companies/{company}/areas - все существующие направления, в которых находится компания
  7. /areas/{area}/companies/{company}/users - все существующие пользователи из компании, существующей в определенной области

Для 1., 2. и 3. Я создаю контроллеры, которые следуют следующему шаблону.

  • AreaController с методами index(), создайте (), store(), show(), edit(), update() и destroy()
GET /areas, index() method,
GET /areas/create, create() method,
POST /areas, store() method,
GET /areas/{area}, show() method,
GET /areas/{area}/edit, edit() method,
PUT/PATCH /areas/{area}, update() method,
DELETE /areas/{area}, destroy() method.

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

  • Случай 1: 4., 5. и 6.
  • Случай 2: 7.

Мой вопрос в том, должен ли я создавать новые контроллеры для каждого случая, так как я хотел бы выполнять различные действия в каждом из них? Если да, то это означает соответственно

  • Случай 1: AreaCompanyController, UserCompanyController и CompanyAreaController
  • Случай 2: AreaCompanyUserController

Примечание: это был полезный ответ, но он не совсем удовлетворил мою озабоченность.


person Tiago Martins Peres 李大仁    schedule 07.01.2021    source источник
comment
Нет ничего проблемного в вашем соглашении и именовании контроллеров (например, AreaCompanyUserController ). Мне нравится, как он выглядит: он легко читается и понятен. Что касается упомянутого поиска, вы можете отделить SearchController, где вы можете использовать различные методы программно.   -  person Tpojka    schedule 08.01.2021


Ответы (2)


Вы можете видеть, что в вложенный ресурс. ">документы, которые могут охватывать ваши случаи 4,5,6. В документах есть PhotoCommentController, который вы описали, что вы его используете (вопрос 1). Для случая вопроса 2 вы можете, например, создать модель для сводной таблицы и так для маршрута и контроллера. Например AreaCompanyUserController если я правильно понимаю, у вас тут area_company сводная таблица с ассоциацией пользователя. Так много пользователей могут быть частью одной и той же area_company ассоциации. Вы можете обойти использование моделей Area и Company с помощью модели AreaCompany, которая будет сводной моделью. Зная идентификатор этой сводной модели, вы можете легко связать область, компанию и пользователей.

class AreaCompany extends Pivot
{
    /** code here */
}

Имея это, вы можете назвать свой ресурсный маршрут /area-companies и /area-companies/{$areaCompany}/users, чтобы избежать тройного вложения. Я предполагаю, что любое из этих решений имеет собственные последствия, такие как планирование подкаталогов для контроллеров, файлов запросов форм, поставщиков, иногда даже файлов маршрутов. Вероятно, слышали и читали тысячи раз, но важно придерживаться последовательного пути. Подумайте, что может быть меньшим техническим долгом в каком-то потенциальном обновлении.

person Tpojka    schedule 10.01.2021

Чтобы упростить процесс отладки и обслуживания проекта, лучше определить контроллер для каждого случая на случай, если что-то пойдет не так, легко отлаживать и решать проблему, поэтому у вас будет

AreaController , UserController , CompanyController
person Francis Tito    schedule 07.01.2021
comment
Уверен, что это подразумевалось в 1., 2. и 3. Вы говорите, что я должен просто придерживаться этого? Если да, то как бы вы предложили поступить с двумя другими случаями? - person Tiago Martins Peres 李大仁; 07.01.2021
comment
да придерживайтесь этого, это реальная помощь в отладке в больших проектах, а в двух других случаях вы можете включить функциональные возможности в один из базовых контроллеров, например, для /users/{user}/companies означает иметь дело с пользователями, которые находятся в компания, поэтому ее Usercontroller или, если функции слишком независимы, просто создайте UserCompanyController - person Francis Tito; 07.01.2021
comment
Точно, я тоже об этом подумал. Что насчет случая 2? - person Tiago Martins Peres 李大仁; 07.01.2021
comment
как это звучит, вам нужны все пользователи, значит, это в Usercontroller с параметрами компании и области - person Francis Tito; 07.01.2021
comment
Дело в том, что у них будут атрибуты, характерные для такого типа пользователей. - person Tiago Martins Peres 李大仁; 07.01.2021