Комментарии 19
Спасибо за перевод, но это не трюки, а документация. К сожалению, многие её не читают, а учатся на таких урывочных статьях и видеоуроках.
Если не ошибаюсь, то не встречал только про метод replicate и потому опасался бы его использовать, т.к. Тейлор уже показал, что не описанное в документации поведение может быть изменено, метод удалён, переименован и т.д., при этом он не считает нужным об этом упоминать в чейнджнотах.
Если не ошибаюсь, то не встречал только про метод replicate и потому опасался бы его использовать, т.к. Тейлор уже показал, что не описанное в документации поведение может быть изменено, метод удалён, переименован и т.д., при этом он не считает нужным об этом упоминать в чейнджнотах.
Главный трюк, по-моему — можно не использовать статические методы для запросов, а просто `(new User())->find(1)`. Вроде мелочь, но это позволяет использовать DI вместо захардкоженных зависимостей в, например, контроллерах или сервисах.
Можно поподробнее, зачем нужен этот трюк?
НЛО прилетело и опубликовало эту надпись здесь
В этом нет смысла, так как в моделях нет статических методов, это просто фасады, которые все равно берут модели из DI контейнера. Так что даже User::find(1) можно все равно замокать в тестах.
Я обычно начинаю запрос так: User::query()->where()->.....->...
Если посмотрите на статический метод query, то там как раз возвращается инстанс билдера для данной модели
Если внимательно посмотреть, то там сначала создаётся новый инстанс модели через new static, у которого вызывается newQuery(). То есть я пишу, когда мне нужен билдер: `(new User())->newQuery()->where()->...`, что позволяет легко разделить new User и все остальное, передавать например инстанс модели параметром, в том числе использовать один инстанс модели для всех запросов в приложении, а не инстанцировать на каждый чих, а потом надеяться, что сборщик мусора разберётся.
ZloAdmin данный перевод появился месяц назад на сайте laravelnews.ru.
никак не могут понять пользу fillable, как бы понятно что эти поля редактируемые и юзер может их изменить, но модель может меняться в разных местах и с разными правами и начинается байда со сценариями (Yii), условиями и т.д. Может удобнее чтоб конструктор говорил что он хочет сделать с модель? User::create($data, ['username', 'password']); $user->update($data, ['username', 'password']) || $user->fillabel(['username', 'password'])->update($data);
Так меньше шансов что джуниор в свойство fillable какое лишнюю запись не запишет
Так меньше шансов что джуниор в свойство fillable какое лишнюю запись не запишет
Ещё нужно обратить внимание, что в примере с full_name используется работа с коллекциями Laravel, а не создаётся запрос к базе данных. Понятно, что это будет иметь совсем другую производительность.
К этому можно добавить обсерверы, которые будут отрабатывать на все эвенты.
Кстати, да, на почти каждый чих бросается эвент.
Кстати, да, на почти каждый чих бросается эвент.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
20 Eloquent ORM трюков