Нужен ли репозиторий для Eloquent??

Всем примет. Недавно прочел несколько статей на тему реализации паттерна репозиторий в фреймворке Laravel. Как реализовать сам паттерн мне стало ясно, но абсолютно непонятно имеет ли смысл этот паттерн, если во всех примерах в качестве точки доступа к БД используют Eloquent?

Я понимаю смысл создания репозитория для QueryBuilder. Это как раз таки позволит отделить логику запросов от бизнес логики, располагаемой в моих сервисах, но нужно ли это при Artive Record? Ведь мне казалось, что модели Eloquent уже в принципе сами по себе выполняют что-то вроде репозитория? То есть они имеют свой базовый удобный интерфейс, который можно расширять локальными и глобальными скоупами. И если это можно делать, но непонятно зачем тогда нужен отдельный слой, который будет делать то же самое...

Еще говорят, что это позволит менять тип хранения данных. Но мне это тоже не совсем ясно. Ведь если я буду использовать ORM, то она определеет в какой-то степени формат вывода данных. Например смежные таблицы Eloquent являются вложенным объектами в объект. То есть даже при выводе массива, мы получим вложенность, которая будет несовместима даже с QueryBuilder, а адаптация биг даты и подведение ее к какому-то формату вывода это неблагодарное дело. А если думать о Redis, то большинство проектов в принципе нельзя перенести на нереляционные БД.

Так вот вопрос. Из всего вышеизложенного мне неясно зачем нужен паттерн репозиторий поверх Eloquent. Может кто-то поделиться своим мнение по этому поводу и по поводу того, когда вам действительно стали полезны репозитории, пусть даже работающие не через Eloquent, а через нативные SQL запросы или еще что-то вроде того...
  • Вопрос задан
  • 423 просмотра
Пригласить эксперта
Ответы на вопрос 5
Tesla
@Tesla
Соль в том, что если вы на 100% в точности не уверены, что паттерн репозиторий вам нужен, значит он вам не нужен. В противном случае вы получите лишний слой абстракции, гору копипасты и дублирование того же самого Eloquent.

Советую мастеркласс по DDD (во второй части про репозиторий), объясняет для чего нужны многие вещи.
Ответ написан
foommiinn
@foommiinn
Junior PHP WEB developer
Вот ещё статья https://m.habr.com/post/316836/
Я лично отказался от репозитория с eloquent
Ответ написан
@Helldar
Eloquent - это уже есть репозиторий для QueryBuilder
Ответ написан
@Adelf
Eloquent прекрасно выполняет свои задачи простой и более-менее эффективной ORM для проектов с CRUD и около таких.
Разумеется частенько нужны запросы посложнее и их выделяют либо в скоупы в самой модели либо в отдельные классы, которые билдят запросы.
Когда задачи становятся еще сложнее, когда нужно уже делить всю нашу модель на read and write части, Eloquent уже начинает подбешивать :) Плюс невозможность отделить логику класса модели от логики её хранения в бд начинает напрягать на любых моделях сложнее одной строки в базе. В итоге в тех проектах, в которых мы хотим отделять Domain логику от всего остального(в том числе базы данных) намного выгоднее отойти от него.
Все эти репозитории нам нужны как раз для этого, чтобы абстрагироваться и отделить логику хранения обьектов доменной логики где-либо. А с элоквентом это практически невозможно. Я это подробно буду разбирать в книжке, которую тут уже отрекламировали - https://leanpub.com/architecture-of-complex-web-ap...

Выделять же классы для некоего query building - вполне нормально для проектов с Eloquent. Вот только не увлекаться желательно. Иногда люди мучаются страшно с этими элоквентовскими билдерами, тогда, когда проще банально написать raw SQL запрос. Обычно это касается всяких отчетов, где много разной интересной агрегации с группировками и т.д.
Ответ написан
neuotq
@neuotq
full stack php, стартапы, прокрастинация
Чет вы сумбурно написали и смешали разные вещи.
В ларавел есть отдельно удобные инструменты/обертки для работы с базой данных, и отдельная вещь это Eloquent ORM по строенная по принципам (анти или нет) патерна ActiveRecord.
Так вот, значит обертки над базой данных ты используешь и реализуешь/используешь удобный тебе подход/патерн к организации моделей. В целом, я советую уходить от Eloquent если проект будет развиваться в перспективе и/или если его будут вести несколько человек, так как начинается брожения моделей-свойств и и методов Eloquent по проекту, что в конце концов приводит к усложнению отладки, развития изменения/добавления редактирования свойств и тд и тп. Конечно если проект простенький, без супер логики и ты знаешь что дальше будет все просто, то можно не парится.
Ну и советую изучить и прочитать этот коммент на тостере напрямую на эту тему:
https://toster.ru/answer?answer_id=1127442#answers...
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы