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

0

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


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

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

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

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