Задать вопрос
@PRodion

В чем преимущества Route Model Binding?

Есть у меня код, в котором вроде бы все понятно.

/**
     * Display the specified resource.
     * 
     * @param string $slug
     * @return \Illuminate\View\View
     */
    public function show(string $slug): \Illuminate\View\View
    {
        $post = Post::where('slug', $slug)
                    ->where('status', 1) // 
                    ->with('reviews')
                    ->firstOrFail();

        return view('post.show', compact('post'));
    }

Однако, более опытные коллеги, сделали замечание, что лучше бы применить Route Model Binding. Говорят, должна улучшится читаемость да и код будет проще.

Однако, при таком подходе, мне придется:

1.) В модели указать Sling как ключ для поиска.
2.) Отдельно подгрузить отношения через load().
3.) Прописать в модели resolveRouteBinding(), дабы можно было применить where().

Собственно... Кода становится не меньше и теперь он не так очевиден т.к разбросан по файлам, а не прописан в одном месте. Так в чем преимущества Route Model Binding?
  • Вопрос задан
  • 332 просмотра
Подписаться 2 Простой Комментировать
Решения вопроса 1
iMedved2009
@iMedved2009
Не люблю людей
К посту jazzus который не поленился и написал все что должен был сказать я, когда предлагал route model binding, добавлю

1. А нахрен в этом конкретном случае делать loadRelation('reviews') - оно автоматом подгрузится при использовании во вьюхе $post->reviews. Eager loading имеет смысл когда вы грузите кучу моделей и у них надо подгрузить отношение - что бы избежать N+1. А в этом случае какое N+1 мы избегаем? Это еще имело смысл в случае loadRelation('reviews.user') - но просто loadRelation('reviews') - нет. Ну и всегда остается вариант когда вы with запихиваете на момент resolve model.

2. Вариант проверки статуса вполне возможно вообще выносить на уровень middleware для фронта через глобал скоуп, я так понимаю у вас этот статус сродни soft deletes

3. На счет количества файлов и разноса функционала. Я так понимаю у вас table-driven development. Ради интереса наберите Domain-Driven Development в ютубе и посмотрите как там. ну к примеру https://www.youtube.com/watch?v=7HXIrEsmlzM&ab_cha...
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
vfreelancer
@vfreelancer
php
с коллегами не согласен. это магия, затрудняет чтение кода. преимущество в простых случаях - нет лишней строки
Ответ написан
@jazzus
1) В твоем случае вообще нужно юзать ресурсные роуты, которые работают с биндингом, а это еще минус строки кода. Далее тебе нужно проверить права доступа, а значит политики авторизации, с ресурсными контроллерами, это еще минус код тк они конектятся одной строкой кода ко всем методам и модель через биндинг передается автоматом в политику. А в этом и есть смысл фрейморка - не писать код самому и не пилить кривые велосипеды.
2) Модель тебе может понадобиться в мидлварях, форм реквестах, политиках, с биндингом тебе не нужно делать на каждом этапе свои одинаковые запросы.
3) Что такого в load неудобного не понял? Тот же самый with.
4) если ты проверяешь права доступа к модели, то тебе обычно не нужны ее отношения и поэтому нет смысла их грузить до проверки в политиках - это будут лишние запросы если авторизация не прошла. Для этого биндинг дает именно то, что тебе надо - чистую модель.
5) Where в модели не нужен. То, что ты проверяешь статус в модели - это проверка доступа, которую нужно делать в политике.
6) Удобно, красиво, быстро и необходимо для полноценного использования Ларавел, а не только роуты, контроллеры и вьюхи как в 99% проектов.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы