Комментарии 10
Как использовать паттерн «репозиторий» в Laravel
Но там предлагают просто возвращать те же самые AR-модели… Уж если следовать паттерну, то нужно вводить слой сущностей (DTOшки, или аналог Entity в симфони), которые знать не знают о базе данных...
НЛО прилетело и опубликовало эту надпись здесь
Согласен, однако достаточно избыточно наращивать поверх AR слои с изоляцией, тогда мы теряем все его плюсы. Я в свою очередь очень много спотыкался об подобные вещи, сейчас AR уже давно не использую выбор пал в сторону DataMapper (Doctrine2).
Если уже работать с AR то нужно принять правила игры.
Если уже работать с AR то нужно принять правила игры.
Раз в два-три месяца стабильно кто-то пишет про репозитории и Eloquent. и как «правильно» их использовать. Притом ни для чего они нужны, ни примера чуток посложнее Post у них не находится.
Преимущества Active Record
Недостатки Active Record
Преимущества использовать Repository (паттерн Data Mapper)
Недостатки использовать Repository
Как всегда, вопрос в расширяемости и гибкости кода, чтобы было проще поддерживать и дорабатывать. Стало понятнее?
- Писать код с Active Record быстро и легко, в том случае, когда свойства объекта прямо соотносятся с колонками в базе данных.
- Сохранение происходит в одном месте, что позволяет легко изучить, как это работает.
Недостатки Active Record
- Модели Active Record нарушаю принципы SOLID. В частности, принцип единой ответственности (SRP — «S» в принципах SOLID). Согласно принципу, доменный объект должен иметь только одну зону ответственности, то есть только свою бизнес-логику. Вызывая его для сохранения данных, вы добавляете ему дополнительную зону ответственности, увеличивая сложность объекта, что усложняет его поддержку и тестирование.
- Реализации сохранения данных тесно связана с бизнес-логикой, а это означает, что если вы позже захотите использовать другую абстракцию для сохранения данных (например для хранения данных в XML-файле, а не в базе данных), то вам придется делать рефакторинг кода.
Преимущества использовать Repository (паттерн Data Mapper)
- Каждый объект имеет свою зону ответственности, тем самым следую принципам SOLID и сохраняя каждый объект простым и по существу.
- Бизнес-логика и сохранение данных связаны слабо, и если вы хотите сохранять данные в XML-файл или какой-нибудь другой формат, вы можете просто написать новый Mapper, не притрагиваясь к доменному объекту.
- Если вы пишете сложную бизнес-логику и хотите внедрить DDD, то использование паттерна Data Mapper лучшее, что можно придумать для отображения доменных моделей в таблицы бд (поля и таблицы могут не совпадать со всеми доменными моделями).
Недостатки использовать Repository
- Вам придется гораздо больше думать, перед тем как написать код.
- В итоге у вас больше объектов в управлении, что немного усложняет код и его отладку.
Как всегда, вопрос в расширяемости и гибкости кода, чтобы было проще поддерживать и дорабатывать. Стало понятнее?
Ну, с википедии(или откуда там) и я смог бы скопипастить… вопрос был именно в использовании Элоквента и Репозитория вместе. Любая сущность с подсущностями и все рушится.
и я смог бы скопипаститьВы лучше попробуйте прочитать и понять.
Любая сущность с подсущностями и все рушится.Почему это должно рушиться? В той же Symfony нормально живут описание зависимостей в модели, а получение данных через репозитории.
Напишите хотя бы один проект на Symfony и тогда в каждом проекте будет не хватать Doctrine с репозиториями.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP-Дайджест № 150 (11 – 25 февраля 2019)