20 Eloquent ORM трюков

[@AmdY]

Спасибо за перевод, но это не трюки, а документация. К сожалению, многие её не читают, а учатся на таких урывочных статьях и видеоуроках.
Если не ошибаюсь, то не встречал только про метод replicate и потому опасался бы его использовать, т.к. Тейлор уже показал, что не описанное в документации поведение может быть изменено, метод удалён, переименован и т.д., при этом он не считает нужным об этом упоминать в чейнджнотах.

[@VolCh]

Главный трюк, по-моему — можно не использовать статические методы для запросов, а просто `(new User())->find(1)`. Вроде мелочь, но это позволяет использовать DI вместо захардкоженных зависимостей в, например, контроллерах или сервисах.

[@DaleMartinWatson]

Можно поподробнее, зачем нужен этот трюк?

[@VolCh]

Избежать очень жёсткой связи в виде вызова статических методов. Тем более под капотом они всё равно приводятся к созданию объекта и вызовов его методов.

[@VolCh]

Да, как вариант.

[@Nicklasos2]

В этом нет смысла, так как в моделях нет статических методов, это просто фасады, которые все равно берут модели из DI контейнера. Так что даже User::find(1) можно все равно замокать в тестах.

[@VolCh]

Явное лучше неявного :)

[@greabock]

1. Это не фасады, (это не фасады, даже в терминах Laravel, не говоря уже о шаблоне проектирования «фасад») это простое проксирование на новый инстанс.
2. Контейнер никак не участвует в этом процессе.
3. Мокать можно, это да.

[@jokpok]

Я обычно начинаю запрос так: User::query()->where()->.....->...

Если посмотрите на статический метод query, то там как раз возвращается инстанс билдера для данной модели

[@VolCh]

Если внимательно посмотреть, то там сначала создаётся новый инстанс модели через new static, у которого вызывается newQuery(). То есть я пишу, когда мне нужен билдер: `(new User())->newQuery()->where()->...`, что позволяет легко разделить new User и все остальное, передавать например инстанс модели параметром, в том числе использовать один инстанс модели для всех запросов в приложении, а не инстанцировать на каждый чих, а потом надеяться, что сборщик мусора разберётся.

[@Pingvi]

ZloAdmin данный перевод появился месяц назад на сайте laravelnews.ru.

[@ZloAdmin]

Не знал: (

[@Arik]

никак не могут понять пользу fillable, как бы понятно что эти поля редактируемые и юзер может их изменить, но модель может меняться в разных местах и с разными правами и начинается байда со сценариями (Yii), условиями и т.д. Может удобнее чтоб конструктор говорил что он хочет сделать с модель? User::create($data, ['username', 'password']); $user->update($data, ['username', 'password']) || $user->fillabel(['username', 'password'])->update($data);
Так меньше шансов что джуниор в свойство fillable какое лишнюю запись не запишет

[@ZloAdmin]

Как я понимаю — это сделано для того что бы создавать модели из request. Ты указываешь те поля которые ты можешь заполнять из вне — и это будет безопасно.

[@ExenJer]

Fillable (и guarded) как раз нужен для того, чтобы не допустить записи/перезапись не нужного поля, в основном из полученного массива.

[@Uhehesh]

Ещё нужно обратить внимание, что в примере с full_name используется работа с коллекциями Laravel, а не создаётся запрос к базе данных. Понятно, что это будет иметь совсем другую производительность.

[@masterjus]

К этому можно добавить обсерверы, которые будут отрабатывать на все эвенты.
Кстати, да, на почти каждый чих бросается эвент.