АБ
Size: a a a
2021 June 13
АБ
Как скажите
A
Просто многие путают репозиторий с чем-то другим и начинают туда пихать логику не только хранения но и бизнес-логику или логику вон хранения деревьев в бд
АБ
Логики хранения деревьев? Разве репозиторий не абстрагирует вас от деталей реализации хранения?
АБ
Если вы storage называете репозиторием то это тоже немного разные понятия
АБ
То как и что хранится в storage к которому обращается репозиторий предмет отдельного обсуждения так как это другой слой
A
Ну в принципе... если отказаться от элоквент и предоставить абстракцию красивую, скрыв все поля, которые нужны для этих нестед сетов и т.д... то наверно можно это назвать репозиторием... ладно
АБ
И тут ещё стоит сказать что нет общего правила для репозитория - только на чтение, на запись, создание
АБ
Да, именно так
A
Но опять таки мою главную мысль это не отменяет
A
С элоквентом репозитории бесполезны
АБ
Не согласится сложно. Вопрос только в том что все же есть места где можно отказаться от элоквента.
АБ
И от любой другой орм
A
Конечно)
VP
Всем привет) подскажите пожалуйста где должны храниться методы которые сохраняют/обновляют/удаляют данные в базе? То есть пример: $note = Note::find($id);
$note->text = $request->text;
$note->status = $request->status;
$note->save(); Куда это лучше впихнуть и вызывать в самом контроллере или прям в контроллере оставлять ?
$note->text = $request->text;
$note->status = $request->status;
$note->save(); Куда это лучше впихнуть и вызывать в самом контроллере или прям в контроллере оставлять ?
АБ
положите в метод сервиса или отдельный класс handler
VP
Вы имеет ввиду в папке Providers создаю себе например NoteServiceProvider и там все эти методы и потом просто через конструктор буду вызывать эти методы с этого класса?
АБ
можно без провайдера
АБ
просто объявите последним аргументов в методе контроллера и получите объект сервиса