AP
слой представления не должен знать о слое хранения
Size: a a a
2020 January 10
Р
Рустам Исакжанов
а чем отличается "сервсис" от "репозиторя" ?
В том, что все будет в одном месте храниться
Р
Представим, что у тебя есть форма и надо сохранить данные из формы в бд
Р
делаешь контроллер, получаешь реквест, в контроллере дергаешь репозиторий ->save
Р
попросили сделать api, ок, делаешь эндпоинт на сохранение, делаешь тоже самое
Р
Попросили получать данные условно из физ магазинов через испорт. Опа, приехали, реквеста нет, в демоне получаем данные из очереди, опять дергаем ->save
Р
Надо сделать возможность из командной строки добавлять данные - ты лепишь 4-ю реализацию
РИ
Руслан
делаешь контроллер, получаешь реквест, в контроллере дергаешь репозиторий ->save
все верно, либо использовать Ioc либо DI все равно будет прослойка
M
Лучше заменить "репозиторий" на слово "класс"
Потому что у spatie например это называется Actions а не Repositories
https://stitcher.io/blog/laravel-beyond-crud-03-actions
Потому что у spatie например это называется Actions а не Repositories
https://stitcher.io/blog/laravel-beyond-crud-03-actions
РИ
Руслан
Надо сделать возможность из командной строки добавлять данные - ты лепишь 4-ю реализацию
это уже заваисит от архитектуры проектирования
Р
Чтобы такого не было, делаешь условный обработчик handler
Р
handler(Command $command)
Р
$command - dto
Р
в контроллере $request = $command
Р
В скрипте $command = []
Р
В сабскрайбере рэббита $command = $serializer->deserialize
Р
но handler один и тот же
Р
И данные принимает в одном и тот же виде и их уже пишет в бд
РИ
Руслан
Чтобы такого не было, делаешь условный обработчик handler
Ты предлагаешь все писать в команды ?
Р
Рустам Исакжанов
Ты предлагаешь все писать в команды ?
Да