«В Вашем примере, видимо, UserRepository будет иметь методы addAddress($userId, $address), getAddress ($userId), saveUser($user, $address, $photos) или getUser($id, $fields) — чтобы получить пользователя с зависимыми сущностями»
ок. Допустим. Я лишь хочу напомнить, что Пользователь — это актор. На него примерно 99.9% всего завязано, при таком подходе в UserRepository будет чуть менее чем всё, что касается пользователя(а его касается вообще всё) и поверьте, я видел такой трындец, получался классический God-class который назывался или UserController или UserRepository, не важно.
И Вы правильно подметили, что ActiveRecord…
CSR — одно из самых неудачных архитектурных решений со времен Б4.
Предлагается для каждой модели написать свой репозиторий и сервис к нему. Но, простите, а что делать, если, например, одной модели оказывается недостаточно? К примеру пользователю понадобился адрес, его куда прикажете запихивать? В UserRepository? Или уже в AddressRepository?
Если в последний, то как передать пользователя? Через id? Тогда будет N+1.
Через ids? Тогда что делать, если сам UserRepository используется в каком-нибудь CustomerService который, не к ночи будет сказано, подтягивает еще какой-нибудь OrderRepositiory?
Т.е. дальше одного…
— Зачем связывать репозиторий с request из веба?
реп может обрабатывать любые запросы, в том числе и запросы с файлами.
— Зачем репозиторий работает с фасадом модели? Почему бы явно не прокинуть билдер?
По той же причине. Реп — универсален, он может работать с любыми моделями, использования билдера привело бы к определению какого-то единого общего интерфейса, который далеко не всегда возможен.
— Что такое Ajax?
Аjax — подход к построению интерактивных пользовательских интерфейсов…
да еще момент с самой задачей...
Допустим задача что то там делает и по какой то причине решила, что не пришло ее время. Что делать?
Правильно — отложить задачу на потом.
Сделать это можно так
public function handle()
{
...
$this->release(self::REPEAT_COOLDOWN);
}
ну а если сделать просто return без release то задача завершится и уйдет из очереди.
Так же несколько полезных команд:
./artisan…
ноу бэд.. однака дополню...
2. Очередь — первые шаги
dispatch($emailJob);
в контроллере лучше $this->dispatch(..) а в произвольно модели добавить трейт Dispatchable
3. Драйвер очереди database
официальная документация настоятельно как бэ намекает использовать Redis, но в нем имеется один подводный камень, который может запросто утянуть на дно, а именно — память.
В идеально сферическом вакууме(там где кони, разумеется) задача в очереди должна практически сразу обрабатываться воркером, но…
Мысль у меня возникает только одна "Дядя Вова, ты..?"
В смысле нафига??? И доколе??? php-fpm, не?
Laravel по-русски
Все так, о чем и речь, нет смысла делать разделение ради разделения, архитектору нужно взвесить возможное развитие проекта. К примеру, кэш вероятно придется однажды заменить с Redis на Memcached — вероятный сценарий, но вряд ли кто-то и когда-то будет значительно менять поток получения данных пользователя
user($id)в контроллере, настолько, что придется подменять репозиторий или сервис, скорее всего смысл выносить логику в обычной жизни придется лишь тогда, когда захочется избежать повторения (скажем, если данные пользователя получаются разными действиями контроллера, нет смысла дублировать код, можно реализовать один методgetUser). При этом, бизнес-логика (логика домена) как правило уже значительно разделена на слои фреймворком: валидация, проверка прав доступа — это все относится к слоям логики, наиболее частые операции. Ровно так же в некоторых сценариях может понадобиться, скажем, отделить DTO, если вводимые данные отличаются от сохраняемых (из головы пример, если для удобства пользователя адрес вводится с помощью JS-плагина с дополнением адресов, на сервер попадают строка и код реестра, а в базу идет расшифрованный адрес, и тут может понадобиться сервис, что выполнит такое преобразование).