Должен ли я вкладывать маршруты в ресурсы в Laravel? - PullRequest
Новая
       30

Должен ли я вкладывать маршруты в ресурсы в Laravel?

0 голосов
/ 18 ноября 2018

Это может быть немного субъективно, но я чувствую, что должна существовать лучшая практика (или даже хороший дизайн, когда речь идет о приложениях Laravel).Поиск в Google приводит к множеству вещей, которые не имеют отношения к фактическим пунктам в этом вопросе.

Скажем, я создаю веб-приложение, в котором есть команды, у которых могут быть проекты, у которых могут быть документы.

Должен ли я спроектировать маршрутизацию так, чтобы документы находились в пределах пути к проектам, к которым они принадлежат, которые затем находятся в пределах пути команд, к которым они принадлежат, или держали вещи на верхнем уровне?* Насколько я могу судить, у этого спектра есть два конца, которые стоит обсудить (другие варианты - только серая середина):

Вложенность

Например, Doc C находится по адресу: / groups / team-a / projects / project-b / documents / doc-c

Это легко сделать, и в файле маршрутизацииЯ могу использовать группы маршрутов , чтобы помочь сохранить структуру в чистоте.Я думаю, что это более логично и, возможно, более удобно для пользователя (они могут сами разработать URL-адреса!).Меня беспокоит то, что я импортирую сложность в каждый запрос страницы:

  • при проверке целостности маршрута (т. Е. Что doc-c действительно принадлежит проекту-b), и
  • что у пользователя есть права доступа к каждому из вложенных активов на всем пути через маршрут.

Должен ли я ставить проверки ворот / политики для каждого ресурса в начале каждого метода контроллера, для каждогопараметр маршрута?Иначе, где это может быть абстрагировано?

А что касается целостности маршрута, я никогда не видел примеров, проверяющих это - так это не распространенный подход?Если мы не проверим целостность маршрута, то на странице может отображаться смешанная информация путем взлома маршрута (например, / groups / team-a / projects / project-Z / documents / doc-c, будет отображаться информация о проекте Z на docстраницы -c).

Без вложений

Пример, документ C находится по адресу: / documents / doc-c

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

Проверка целостности не требуется, и контроллер предварительно определит другие активы, показанные для генерации представления.

Но достаточно ли хорош этот UX?Большинство сайтов, которые я видел, не делают этого.

Ответы [ 4 ]

0 голосов
/ 30 ноября 2018

Это может быть немного отклонением от первоначального вопроса, но я чувствую, что выступление Адама Уотана на Laracon US 2017 может быть полезным ресурсом для этого обсуждения. (https://www.youtube.com/watch?v=MF0jFKvS4SI)

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

Хранение материала "CRUDY by design", как его называет Адам, одна вещь, которую вы достигнете, imo, - это упрощение названий маршрутов. Если бы я работал в группе, я бы предпочел эту модель.

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

0 голосов
/ 28 ноября 2018

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

В последнее время я видел твит от Тейлора Отвелла, в котором говорилось, что он устарел в разделе вложенных маршрутов из документов Laravel, потому что он этого не предпочитал, а когда вы открываете Laracasts, вы видите, что Джеффри реализует эту концепцию как /series/php-testing/episodes/hello-world.

Как я уже сказал, это тихий спор, и когда дело доходит до такого выбора, я всегда делаю то, что мне нравится.Так что, будь я на твоем месте, я бы не вложил ни teams, ни projects, но, может быть, я бы вложил projects/documents, я не всегда вкладываю в гнездо.

0 голосов
/ 29 ноября 2018

Это интересный вопрос - как вы упомянули, он может быть немного субъективным, но заслуживающим обсуждения.

Вы касаетесь нескольких моментов, поэтому я попытаюсь рассмотреть их отдельно.

Вложение против не вложения

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

  • Формат ресурса / идентификатора довольно стандартен и выразителен для API
  • это облегчает документирование
  • это упрощает динамическое построение запросов API для приложения пользователя

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

Маршруты действуют и помогают с UX - они почти крошка и должны выглядеть именно так.

Итак, я бы определенно вкладывал в маршруты браузера, а определенно не в API.

целостность маршрута

Реальная суть вашего вопроса, я думаю, касается целостности маршрута. Я думаю, что независимо от того, решите вы вкладывать или нет, вам нужно проверять свои разрешения, исходя из предположения, что кто-то вмешивается в URL-адреса - так же, как вы предполагаете, что пользователь вмешался в ввод формы.

По сути, ваши маршруты (вложенные или нет) действуют как входные данные, и вам нужно будет это проверить. Промежуточное программное обеспечение на уровне маршрутов является одним из подходов, но часто оно слишком универсальное, чтобы решать какие-либо сложные задачи, поэтому вам может быть проще справиться с ним с помощью промежуточного программного обеспечения контроллера (https://laravel.com/docs/5.7/controllers#controller-middleware).

Так что вы можете сделать что-то вроде: 

public function __construct()
{
    $this->middleware('auth');

    $this->middleware('canViewProject')->only('show');

    $this->middleware('canEditProject')->except('store');
}

Используете ли вы Gates, Policies или просто старое промежуточное ПО, вероятно, будет зависеть от сложности проекта - но вышеизложенное применимо независимо от того - обрабатывать URL-адреса как входные данные и проверять соответственно

0 голосов
/ 28 ноября 2018

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

Для вещей, связанных с ролями, отметьте https://github.com/spatie/laravel-permission, хороший пакет

Например: 

Route::group(['middleware' => ['role:super-admin']], function () {
    //
});

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

Принимайте роли, такие как руководитель проекта, разработчик.

Группируйте свои маршруты на основе ролей& назначьте нужное промежуточное программное обеспечение так, как вам нужно.

Для URL: / groups / team-a / projects / project-b / documents / doc-c

Убедитесь, что аутентифицированный пользователь играет роль в команде-a & project-b (Вы можете проверить это в Middleware, Controller или пользовательском сервис-провайдере в любом месте, где вам нужно).

Также просто отметьте https://laravelvoyager.com/

Спасибо

...