Может войдёшь?
Черновики Написать статью Профиль

Комментарии nailfor

CSR — одно из самых неудачных архитектурных решений со времен Б4.

Предлагается для каждой модели написать свой репозиторий и сервис к нему. Но, простите, а что делать, если, например, одной модели оказывается недостаточно? К примеру пользователю понадобился адрес, его куда прикажете запихивать? В UserRepository? Или уже в AddressRepository?
Если в последний, то как передать пользователя? Через id? Тогда будет N+1.
Через ids? Тогда что делать, если сам UserRepository используется в каком-нибудь CustomerService который, не к ночи будет сказано, подтягивает еще какой-нибудь OrderRepositiory?
Т.е. дальше одного…

— Зачем связывать репозиторий с request из веба?

реп может обрабатывать любые запросы, в том числе и запросы с файлами.

— Зачем репозиторий работает с фасадом модели? Почему бы явно не прокинуть билдер?
По той же причине. Реп — универсален, он может работать с любыми моделями, использования билдера привело бы к определению какого-то единого общего интерфейса, который далеко не всегда возможен.

— Что такое Ajax?
Аjax — подход к построению интерактивных пользовательских интерфейсов…

alexMt

1. CustomersController завязан на конкретной реализации CustomersRepositary а не на абстракции остальные классы тоже — это уже не SOLID
2. Почему репозиторий знает про необходимый формат данных? CustomersAgeCollectionResource — нарушение SOLID

"— Вы на ajax, веб будете делать новый репозиторий?
Естественно. SOLID как раз об этом."
Какой принцип солид это утверждает? Этим вы нарушаете принцип DRY

"на самом деле избавился. Переменная в контроллере содержит имя переменной реквеста, которая подключает разные репозитарии, в зависимости. Опять же здесь для простоты это пропущено.
"
Тот же if только выше

да еще момент с самой задачей...
Допустим задача что то там делает и по какой то причине решила, что не пришло ее время. Что делать?
Правильно — отложить задачу на потом.
Сделать это можно так

public function handle()
{
...
$this->release(self::REPEAT_COOLDOWN);
}

ну а если сделать просто return без release то задача завершится и уйдет из очереди.
Так же несколько полезных команд:
./artisan…

ноу бэд.. однака дополню...

2. Очередь — первые шаги

dispatch($emailJob);
в контроллере лучше $this->dispatch(..) а в произвольно модели добавить трейт Dispatchable

3. Драйвер очереди database

официальная документация настоятельно как бэ намекает использовать Redis, но в нем имеется один подводный камень, который может запросто утянуть на дно, а именно — память.
В идеально сферическом вакууме(там где кони, разумеется) задача в очереди должна практически сразу обрабатываться воркером, но…

Мысль у меня возникает только одна "Дядя Вова, ты..?" В смысле нафига??? И доколе??? php-fpm, не?

← Назад | Дальше → Движется на Habravel