PHP-Дайджест № 150 (11 – 25 февраля 2019)

[trawl]

Как использовать паттерн «репозиторий» в Laravel

Но там предлагают просто возвращать те же самые AR-модели… Уж если следовать паттерну, то нужно вводить слой сущностей (DTOшки, или аналог Entity в симфони), которые знать не знают о базе данных...

[nepster-web]

В этом случае нужно думать о реляциях, типах и изоляции.

[nepster-web]

Согласен, однако достаточно избыточно наращивать поверх AR слои с изоляцией, тогда мы теряем все его плюсы. Я в свою очередь очень много спотыкался об подобные вещи, сейчас AR уже давно не использую выбор пал в сторону DataMapper (Doctrine2).

Если уже работать с AR то нужно принять правила игры.

[Adelf]

Раз в два-три месяца стабильно кто-то пишет про репозитории и Eloquent. и как «правильно» их использовать. Притом ни для чего они нужны, ни примера чуток посложнее Post у них не находится.

[evgeniy_p]

Преимущества Active Record

• Писать код с Active Record быстро и легко, в том случае, когда свойства объекта прямо соотносятся с колонками в базе данных.
• Сохранение происходит в одном месте, что позволяет легко изучить, как это работает.

Недостатки Active Record

• Модели Active Record нарушаю принципы SOLID. В частности, принцип единой ответственности (SRP — «S» в принципах SOLID). Согласно принципу, доменный объект должен иметь только одну зону ответственности, то есть только свою бизнес-логику. Вызывая его для сохранения данных, вы добавляете ему дополнительную зону ответственности, увеличивая сложность объекта, что усложняет его поддержку и тестирование.
• Реализации сохранения данных тесно связана с бизнес-логикой, а это означает, что если вы позже захотите использовать другую абстракцию для сохранения данных (например для хранения данных в XML-файле, а не в базе данных), то вам придется делать рефакторинг кода.

Преимущества использовать Repository (паттерн Data Mapper)

• Каждый объект имеет свою зону ответственности, тем самым следую принципам SOLID и сохраняя каждый объект простым и по существу.
• Бизнес-логика и сохранение данных связаны слабо, и если вы хотите сохранять данные в XML-файл или какой-нибудь другой формат, вы можете просто написать новый Mapper, не притрагиваясь к доменному объекту.
• Если вы пишете сложную бизнес-логику и хотите внедрить DDD, то использование паттерна Data Mapper лучшее, что можно придумать для отображения доменных моделей в таблицы бд (поля и таблицы могут не совпадать со всеми доменными моделями).

Недостатки использовать Repository

• Вам придется гораздо больше думать, перед тем как написать код.
• В итоге у вас больше объектов в управлении, что немного усложняет код и его отладку.

Как всегда, вопрос в расширяемости и гибкости кода, чтобы было проще поддерживать и дорабатывать. Стало понятнее?

[Adelf]

Ну, с википедии(или откуда там) и я смог бы скопипастить… вопрос был именно в использовании Элоквента и Репозитория вместе. Любая сущность с подсущностями и все рушится.

[evgeniy_p]

и я смог бы скопипастить

Вы лучше попробуйте прочитать и понять.

Любая сущность с подсущностями и все рушится.

Почему это должно рушиться? В той же Symfony нормально живут описание зависимостей в модели, а получение данных через репозитории.

Напишите хотя бы один проект на Symfony и тогда в каждом проекте будет не хватать Doctrine с репозиториями.

[Adelf]

А самому прочитать внимательно? Доктрина с репозиториями — нормально. Элоквент с репозиториями — бесполезное жонглирование паттерном.