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

Question

[PRodion]

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

/**
     * 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?

Answer 1

[Дмитрий]

К посту 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...

Comments

[PRodion]

1.) Review — отзывы. Их довольно много. 2.) Как-то сам и не додумался до этого. Отличная идея. Нет ли примера реализации?

[Дмитрий]

PRodion,
1. Плевать сколько. Еще раз eager loading решает проблему N+1. То есть вот такой пример:

DB::enableQueryLog();
$posts = Post::get();
foreach($posts as $post){
    dump($post->reviews);
}
dd(DB::getQueryLog());

Порождает проблему N+1. У вас сначала идет запрос select * from posts; а потом в цикле на каждой итерации идет select * from reviews where post_id = ?. И что бы у вас было не N+1 запросов, а 2 - используется with - eager loading. А если у вас нет цикла проходящего по posts - вы выдернули 1 post, а у него все reviews - в чем цимес eager loading? У вас физически не может быть N+1. У вас всегда будет 2 запроса.

2.

Route::group(['middleware' => 'front'], function (){

});

class FrontMiddleware
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure(\Illuminate\Http\Request): (\Illuminate\Http\Response|\Illuminate\Http\RedirectResponse)  $next
     * @return \Illuminate\Http\Response|\Illuminate\Http\RedirectResponse
     */
    public function handle(Request $request, Closure $next)
    {
        Post::addGlobalScope(new StatusScope);
        Review::addGlobalScope(new StatusScope);
        SomeMore::addGlobalScope(new StatusScope);
        return $next($request);
    }
}

[PRodion]

foreach($post->reviews as $review) делается во view. и это пораждает N+1. что не так?

[Дмитрий]

PRodion, с чего бы это? у вас при вызове @foreach($post->reviews as $review) через магические методы __call laravel обнаруживает что это relation - грузит его и все. дело с концом. или вы думаете он по одной записи review дергает? А вот когда в цикле идет foreach($posts as $post){ dump($post->reviews); } - вот тогда у вас N+1, потому что он каждый раз в цикле лезет - обнаруживает что это relation и каждый раз дергает

Вот честно говоря лучше бы вы с этим разобрались - нежели с тем что лучше route model binding или выборка модели в контроллере, или сколько пробелов ставить. Понимание того как работают запросы модели и прочее - куда как важнее.

[PRodion]

И правда. У меня было не правильно представление. Вы открыли мне глаза. Последний вопрос на счет Route Model Binding. Laravel самостоятельно проверяет данные, которые приходят от пользователя (slug поста)? Или нужно отдельно валидацию делать? Нужно ли делать проверку, что slug может быть только из букв и - ? То есть, может ли недоброжелатель отправить туда что-то вредное.

[jazzus]

Ну у него во вьюхе проверка может быть, что reviews есть и тогда лучше вообще сохранить в переменную. Я load в show юзаю для js фронта и сети ресурсов где, например, добавишь reviews.user и будет n+1 автоматом или null с whenLoaded. Проще загрузить/сохранить в переменные, чем потом за этим следить.

[Дмитрий]

PRodion, во-первых что бы он туда не отправил если вы не залезли в классы ларки и не перефигачили все - будут использоваться prepared statement - которые шлет запрос и данные к запросу отдельно друг от друга - и какое бы дерьмо кто либо туда не запихал - всем пох.
второе: и не смотря на это вы можете обвешать проверками.

[Дмитрий]

jazzus, ну я указал что если reviews.user - то надо использовать eager loading.

[jazzus]

Дмитрий, я имею ввиду post.reviews.user т.е. даже если идет от биндинг модели, но это впринципе туда же

[jazzus]

PRodion, короче установи дебагбар и не ошибешься)

[PRodion]

Дмитрий jazzus Спасибо. Теперь я понимаю, на сколько я могу упростить код с помощью Model Binding и сделать его легче в обслуживании (на перспективу).

[Дмитрий]

PRodion, DDD гляньте - на перспективу

[PRodion]

Если в моем примере show(string $slug) тип был string. show(Post $post), то какой будет тип сейчас? простите за нубские вопросы (

[Дмитрий]

PRodion, дык тип App\Models\Post и будет. собственно и написано show(Post $post)

[PRodion]

я про коментирование (PHPDoc) @param string $slug здесь получается просто @param App\Models\Post?

[Дмитрий]

PRodion,

/**
     * Display the specified resource.
     * 
     * @param App\Models\Post $post
     * @return \Illuminate\View\View
     */
    public function show(App\Models\Post $post): \Illuminate\View\View
    {
        return view('post.show', ['post' => $post]);
    }

[PRodion]

Выходит, проблема N+1 у меня была, но решал я ее не в том месте. Надо $post->load('reviews.user') делать, верно?

[Дмитрий]

PRodion, если вы у ревью дергаете отношение user - то конечно

[Дмитрий]

PRodion, еще раз поставьте вывод всех запросов и будет вам счастье - либо дебаг бар, либо руками через DB::enableQueryLog(). Там не трудно обнаружить n+1

[PRodion]

@jazzus

у него во вьюхе проверка может быть

Вот это уже будет n+1 что ли?

$post->load('reviews.user');

if ($post->reviews) {
    foreach ($post->reviews as $review) {
        // 
    }
}

[jazzus]

PRodion, блин.. роуты
Route::resource('posts', PostController::class);
контроллер

public function __construct()
    {
        $this->authorizeResource(Post::class, 'post');
    }

    public function show(Post $post)
    {
        $post->load('reviews.user');

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

политика

public function view(?User $user, Post $post): bool
    {
        if ($user && $user->can('update', $post)) {
            return true;
        }

        return $post->is_good;
    }

    public function update(User $user, Post $post): bool
    {
        return $post->user_id === $user->id;
    }

модель

const STATUS__GOOD = 1;

    public function getRouteKeyName(): string
    {
        return 'slug';
    }

    public function getIsGoodAttribute(): bool
    {
        return $this->status === self::STATUS__GOOD;
    }

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

[NubasLol]

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

Особенно круто это работает с blade, когда часть шаблона отрендерится, в другой части будет exception из-за того, что отношения по какой-то причине не подгрузились

[Дмитрий]

NubasLol, по какой?

[NubasLol]

Дмитрий, назвали не правильно, заблокировали таблицу на чтение, база отвалилась

[NubasLol]

Ломается mvc - во вью отдаются не готовые данные, а запросы ладно в контроллере делаете, вы еще предлагает их во вьюху перенести, потом он еще логику навесит во вью на этот запрос

[Дмитрий]

NubasLol,
1. круто. И в чем разница отловить 500 на этапе вызова контроллера или на этапе рендеринга вьюхи вы и в том и в том случае получите страницу 500. Разница даже во времени будет 0, ибо все extentd рендирятся после рендеринга конкретной вьюхи

2. Ломается простите что?

3. Что я предлагаю перенести во вьюху? Использование магических методов моделей Ларки? Ну они для этого сделаны. Обращение к свойству модели идёт ровно через этот же метод и может быть обвешано кучей мутаций, кастингов и прочих веселух. Вы рассматриваете только поломаный релейшен? А поломанную мутацию? Не готовые данные все дела.

Не нравится магия ларки - есть симфони с доктриной. Но ларка предлагает такой путь

4. Для ваших поломок существуют тесты и мониторинг. Попытка получить 500 в лоб как можно раньше решение так себе. А поломанная база положит ларку на этапе ресолва модели.

З.ы и опять же таки - ну залезьте в route service provider и определите там нужные with - и у вас ларка отвалится ещё раньше. Судя по всем для вас это успех

[NubasLol]

Дмитрий,

PRodion, DDD гляньте - на перспективу

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

Они даже сделали preventLazyLoading, потому что с этой магией легко где-то забыть подгрузить значение, как итог получаем н+1, а когда запросы разбросаны по всем слоям приложения отлов их становится проблемой

Ломается простите что

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

обвешано кучей мутаций, кастингов и прочих веселух

Ну это говнокод, бывают полезные касты, но точно не ходящие в базу данных или по http например, преобразование данных - ок

[Дмитрий]

NubasLol,

Разделение приложения на слои

И ещё раз - с точки зрения ларки обращение к $model->attribute тождественно обращению $model->relation. Если вас это не устраивает - зачем жрать кактус?

Ну это говнокод, бывают полезные касты

Без всяких обращений в бд или по http кастинг может прервать рендеринг вьюхи и вывалить 500 - долго ли умеючи? Чо делать то? На уровне контроллера перебирать аттрибуты?

[NubasLol]

Дмитрий,

$model->attribute тождественно обращению $model->relation.

В первом случае не идет запрос в базу

Чо делать то?

ну в идеале - во вью отдавать dto, что бы там вообще никакой логики не было, и модели

[NubasLol]

DB::enableQueryLog();
$posts = Post::get();
foreach($posts as $post){
dump($post->reviews);
}
dd(DB::getQueryLog());

dd(DB::getQueryLog()) - тоже тогда во вью пихать?

[Дмитрий]

NubasLol, прекрасно. Я вам ещё раз говорю согласно ларке загрузка релейшена это банальный кастинг атрибута. Но Окей. Рассмотриваем ваш вариант.

Порушили mvc

public function edit(Post $post){
   return view(‘view’)->with(‘post’, $post);
}

Не порушили mvc

public function edit(Post $post){
   $post->load(‘user’);
   return view(‘view’)->with(‘post’, $post);
}

А теперь закроем тему mvc. View не должно содержать логику и прочее. Оно и не содержит - логика обработки обращения лежит себе в модели. По этому никаких нарушений mvc нет - это ваша фантазия. На каком нибудь голимом getLogicAttribute может висеть вагон логике. Но обращение во вью к $model->logic никоим образом не нарушает mvc. Ибо логика в модели. По этому завязывайте вы свои крики о том что mvc порушили

ну в идеале - во вью отдавать dto, что бы там вообще никакой логики не было, и модели

Ну для апи есть resource из которых вообщем то можно наколхозить так называемые view models но из коробки такой возможности нет

[Дмитрий]

NubasLol, его вообще никуда пихать не надо. Надо один раз посмотреть понять и простить

[NubasLol]

Дмитрий, Я понял, согласен есть логика в твоих словах. Просто в свое время настрадался с запросами во вью, очень сильно, и теперь максимально их избегаю и всем советую

Благо года 2 уже с шаблонами не работал, только json

[Дмитрий]

NubasLol, мне тоже уже лениво сраться. :) Мир

Answer 2

[Vfreelance]

с коллегами не согласен. это магия, затрудняет чтение кода. преимущество в простых случаях - нет лишней строки

Comments

[jazzus]

Каким образом это затрудняет чтение? Что за ересь. Любой фреймворк создан для ускорения и облегчение работы программиста, чем биндинг и занимается. Постоянно юзаю, ни разу не сталкивался с трудностями чтения, в отличие от самоделкиных велосипедов.

[Дмитрий]

в чем заключается затруднение - вам сразу в контроллер передается нужная модель?

[Vfreelance]

Дмитрий, попробуйте мыслить нетопорно. например, в контролере нужна не просто модель findOrFail() в еще в запросе должен быть with() и whereHas. повторю: в простых случаях это удобно и оправдано, нет лишей строки кода

[Дмитрий]

Vfreelance, я пробую мыслить не топорно. у вас есть возможность определить то как будет выдергиваться модель. вы можете поставить whereHas, where, with - и вообще что угодно. Не говоря о том что в каких то случаях вы можете вынести на уровень самой модели, на уровень миддлеваре. Вопрос в том как и что это грузится.

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

[jazzus]

Vfreelance, любые where для фильтрации в show это говнокод. Авторизацией доступа к ресурсу занимаются политики. Это удобно, переиспользуемо, хорошо читаемо и не топорно.

Answer 3

[jazzus]

1) В твоем случае вообще нужно юзать ресурсные роуты, которые работают с биндингом, а это еще минус строки кода. Далее тебе нужно проверить права доступа, а значит политики авторизации, с ресурсными контроллерами, это еще минус код тк они конектятся одной строкой кода ко всем методам и модель через биндинг передается автоматом в политику. А в этом и есть смысл фрейморка - не писать код самому и не пилить кривые велосипеды.
2) Модель тебе может понадобиться в мидлварях, форм реквестах, политиках, с биндингом тебе не нужно делать на каждом этапе свои одинаковые запросы.
3) Что такого в load неудобного не понял? Тот же самый with.
4) если ты проверяешь права доступа к модели, то тебе обычно не нужны ее отношения и поэтому нет смысла их грузить до проверки в политиках - это будут лишние запросы если авторизация не прошла. Для этого биндинг дает именно то, что тебе надо - чистую модель.
5) Where в модели не нужен. То, что ты проверяешь статус в модели - это проверка доступа, которую нужно делать в политике.
6) Удобно, красиво, быстро и необходимо для полноценного использования Ларавел, а не только роуты, контроллеры и вьюхи как в 99% проектов.

Comments

[PRodion]

Честно сказать, вы сильно меня запутали. Проверку, опубликован пост или находится в черновике — нужно проверять в политике?

[jazzus]

PRodion, конечно. Это авторизация доступа к ресурсу. Для черновика тебе нужно еще дать доступ автору поста и др условия, например, $post->is_approved и полетели велосипеды в where. +404 который возвращает firstOrFail неправильный код ответа. Можно и глобальный скоуп, но это если действительно как soft delete, но на проде обычно запросов админских гораздо больше чем пользовательских и глобальные скоупы нужно будет держать в голове и прописывать исключения.

[NubasLol]

Это все работает только с простым crud уровня блога, для чего-то хоть сколько то сложного, использовать биндинг модели в контроллер = стрелять тебе в ногу

[jazzus]

NubasLol, пример