Ads
Comments
Спасибо за перевод, но это не трюки, а документация. К сожалению, многие её не читают, а учатся на таких урывочных статьях и видеоуроках.
Если не ошибаюсь, то не встречал только про метод replicate и потому опасался бы его использовать, т.к. Тейлор уже показал, что не описанное в документации поведение может быть изменено, метод удалён, переименован и т.д., при этом он не считает нужным об этом упоминать в чейнджнотах.
Главный трюк, по-моему — можно не использовать статические методы для запросов, а просто `(new User())->find(1)`. Вроде мелочь, но это позволяет использовать DI вместо захардкоженных зависимостей в, например, контроллерах или сервисах.
Избежать очень жёсткой связи в виде вызова статических методов. Тем более под капотом они всё равно приводятся к созданию объекта и вызовов его методов.
Вы предлагате new User() передавать как аргумент в конструктор контроллера и юзать аки репозиторий?
В этом нет смысла, так как в моделях нет статических методов, это просто фасады, которые все равно берут модели из DI контейнера. Так что даже User::find(1) можно все равно замокать в тестах.
1. Это не фасады, (это не фасады, даже в терминах Laravel, не говоря уже о шаблоне проектирования «фасад») это простое проксирование на новый инстанс.
2. Контейнер никак не участвует в этом процессе.
3. Мокать можно, это да.

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


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

Если внимательно посмотреть, то там сначала создаётся новый инстанс модели через new static, у которого вызывается newQuery(). То есть я пишу, когда мне нужен билдер: `(new User())->newQuery()->where()->...`, что позволяет легко разделить new User и все остальное, передавать например инстанс модели параметром, в том числе использовать один инстанс модели для всех запросов в приложении, а не инстанцировать на каждый чих, а потом надеяться, что сборщик мусора разберётся.
никак не могут понять пользу fillable, как бы понятно что эти поля редактируемые и юзер может их изменить, но модель может меняться в разных местах и с разными правами и начинается байда со сценариями (Yii), условиями и т.д. Может удобнее чтоб конструктор говорил что он хочет сделать с модель? User::create($data, ['username', 'password']); $user->update($data, ['username', 'password']) || $user->fillabel(['username', 'password'])->update($data);
Так меньше шансов что джуниор в свойство fillable какое лишнюю запись не запишет
Как я понимаю — это сделано для того что бы создавать модели из request. Ты указываешь те поля которые ты можешь заполнять из вне — и это будет безопасно.
Fillable (и guarded) как раз нужен для того, чтобы не допустить записи/перезапись не нужного поля, в основном из полученного массива.

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

К этому можно добавить обсерверы, которые будут отрабатывать на все эвенты.
Кстати, да, на почти каждый чих бросается эвент.
Only those users with full accounts are able to leave comments. Log in, please.