Репозиторий и ActiveRecord, хорошая ли идея возвращать модели?

Question

[nepster-web]

Несколько месяцев разрабатывал на laravel5 и понял, что весьма накосячил с репозиториями, а точнее КПД получил примерно 0. Сейчас пытаюсь понять, как все это дело исправить и узнать мнения разных спецов.

Когда я лазил по интернету, то находил различные приложения, где примерно так-же косячат как и я. Вот пример такого приложения:
https://github.com/Bottelet/Flarepoint-crm/

Репозиторий:
https://github.com/Bottelet/Flarepoint-crm/blob/de...

Собственно какие тут проблемы:
- логика в репозитории
- дубль запроса в методе update (мы передаем $id, из модели, чтобы получить модель). У себя в приложении я накосячил еще более жестче, так как передавал еще и модель, чтобы избавиться от этого запроса.
- нарушение единой ответственности (bcrypt)
- возврат модели в качестве результата из репозитория.

Тоесть, если использовать репозитории, как действительно репозитрои и подменить скажем запрос модели на запрос с помощью квери билдера и в один прекрасный день из репозитория вернется не модель, а коллекция, то это не гарантирует никакой стабильной работы приложения.

От сюда вопрос, зачем тут репозитории, если это абстрактное хранилище над моделями, а не абстрактное хранилище в целом?

Ну и основной вопрос, в правильном ли я направлении формирую мысли, и как подобный подход с репозиториями можно реализовать правильно ?

Comments

[Максим Тимофеев]

nepster09 Извини за офтоп, но ты человек тут не новый и достаточно адекватный. Вижу пересел с yii2 а laravel5. Черкни пару строк о ощущениях.

[nepster-web]

Максим Тимофеев: Скажу сразу, я на него пересел не по своему желанию, а потому, что так решило руководство из-за его дикой популярности за рубежом. По с равнению с Yii2, почти все такое-же, разница может быть в том, что laravel5 чуть более грамотнее спроектирован, возможно в целом сообщество чуть сильнее, в целом с Yii2 на Laravel5 и обратно вполне легко мигрировать. Работая с laravel5 я открыл для себя несколько новых подходов, возможно еще несколько фитч, которые не знал как применить в yii2, но в целом можно сказать, что инструменты из одной серии.

Могу сразу сказать несколько небольших минусов Laravel5:
- Фасады. Это весьма раздражающий паттерно, вроде можно и подменить все туда и сюда, но без доп. плагинов у вас не будет автокомплита в ide
- Дока. В этом плане Laravel5 по сравнению с Yii2 отдыхает.
- Еще заметил такую штуку, что в Yii2 куча джунов, они сидят не парятся и пишут лапшекод. В ларавеле сидят, такие как я, которые типа "горе-архитекторы" и выдумывают реализации всяких там паттернов. В результате можно наблюдать весьма большое разнообразие в подходах.
- AR все-же мне больше нравится в Yii2, хотя по большому счету, по возможностям она почти одинаковые. Но опять таки даже с ide плагином автокомплита в laravel5 AR нет.

В общем мне кажется любые фраэмворки, где есть AR, почти одинаковые. Что cake, что yii, что laravel. Будет 80% всего одинакового, пару ответвлений в какой-то паттерн типа Фасада, дока где лучше, где хуже а в остальном только к синтаксису привыкать.

Я щас посматриваю в более глубокие дебри ооп, а то, что в Yii2, что в Laravel5 сидит AR, а эта штука мне весьма приелась.

[Максим Тимофеев]

nepster09: Спасибо, огромное.

[AlikDex]

Блин, вот прямо ответ на мои чуть было небыло грабли. Долго думал как Yii2 прикрутить репозитарий. И так и сяк обсасывал варианты, но пришел к выводу что AR самодостаточен и не нужно городить велосипеды(хотя до чертиков хочется). А тут прямо в тему вопрос =) Спасибо чтоль.

Answer 1

[Вячеслав Плиско]

Это типичный пример, когда люди не сами доходят до паттернов, а начитываются умных книг и суют свои репозитории и ддд без понятия зачем это нужно.
Сколько уже статей видел об использовании репозиториев в laravel, все прдлагают куегкт Model::all() и т.д. Плевать, что возвращают всё тот же Eloquent, который пытаются убрать.

В проектах на symfony даже при наличии doctrine творится такой же ад. То. что люди не умеют делать нормальные репозитории указывает на то, что оно им и не надо было такой абстракции. Для 99% проектов вообще не стоит тащить абстракции вроде репозиториев.

Comments

[nepster-web]

Согласен, но тут вопрос изоляции и подмены репозитория в случае чего. А часто этот случай появляется, когда нужно оптимизировать запросы к базе. Вы наверно намекаете, на то, что 99% проектов не стреляют и не получают посещаемость, при которой уже нужна оптимизация.

В любом случае мне даже с точки зрения обучения интересно как это можно разрулить. В случае с симфони не совсем вас понял, там же по проекту гуляют сущности, а не модели. Сущности как правило не несут в себе логику. Но в любом случае нужна обертка по верх доктриновских репозиториев, на случай той-же оптимизации и получания данных с помощью чистого SQL.

[IvanY]

nepster09:
> Сущности как правило не несут в себе логику.
что тогда они несут? Сущности ведь для этого и предназначены.
В Doctrine есть DQL, его обычно и используют в подобных случаях, при этом не создавая отдельных имплементаций репозитория для DQL и ORM.

[nepster-web]

IvanY: Вы что-то путаете. Сущность это пачка геттеров и сеттеров и по сути просто коробка для данных.

[Вячеслав Плиско]

nepster09: да, очень мало разработчиков работает с коробочными продуктами, где нужно действительно закладывать гибкость, т.к. ядро должно быть upgrade safe для сторонних надстроек. В большинстве проектов в любой момент можно поменять или зарефакторить любой кусок кода.

Если не говнокодить цепочки квери билдера прямо в контроллере, а хотя бы вынести в отдельный метод модели, то его можно будет рефакторить и оптимизировать как угодно, хоть поменять на другой сторадж.

[nepster-web]

Вячеслав Плиско: да, но тут важен еще формат данных. Тоесть если вы в 1 случае возвращаете модель, во втором массив а в третьем коллекцию, то никто не гарантирует, что кто-то не воспользовался где-то там индивидуальной особенностью каждого варианта. Поэтому формат возврата данных должен быть стандартизирован. Например коллекции или сущности. Но тут еще очень много вопросов в плане реляций и тп.

В общем как-то через весьма серьезную боль и рефакторинг я прихожу к таким мыслям.

[Вячеслав Плиско]

nepster09: да, в форматами беда, потому я не пытаюсь играть в репозитории с eloquent, а спокойно пользуюсь как ar и засовываю перфекционизм куда подальше. Правда есть https://github.com/analogueorm/analogue, но его не пробовал. Я больше думаю о js, чем о php коде, каким бы он гавёным не был, бэкенд последние годы отнимает максимум 10% времени.

Answer 2

[index0h]

Ну и основной вопрос, в правильном ли я направлении формирую мысли, и как подобный подход с репозиториями можно реализовать правильно ?

Если хотите по правильному - не используйте ларавелевскую ORM, "воевать" с фреймворком - это дело не благодарное.
Паттерн Repository как правило предполагает еще наличие Entity. Entity - это объект, умеющих хранить в себе данные и проверять их при установке. Репозиторий работает только с Entity и только с БД. Никаких bcrypt, работы с файлами, никаких уведомлений...
Не стоит использовать публичные свойства. В противном случае вы не сможете гарантировать корректность данных в вашем Entity, как следствие всюду их придется проверять. Используйте тайпхинтинг.
Так же рекомендую почитать: Попросили проверить код, на что смотреть нужно?

Answer 3

[dmitriy]

1. репозитрии должны инкапсулировать логику работы с хранилищем все остальное выносите в сервисы пример
2. Возвращаться должны не модели а Entity, модель в laravel это activerecord. Возможно по этому репозитории в laravel избыточны.
3. вот хороший видос

Comments

[Вячеслав Плиско]

Не. Моделей в laravel нет, если скатываться до всякого DDD, то active record стоит воспринимать как репозитории.

[nepster-web]

Вячеслав Плиско: В АР много магии, а еще мутаторы/аксессуары и тп. Поэтому АР я бы воспринимал как гибрид между:
- Entity
- Presenter
- Repository
- Ну и некое подобие Модели в плане логики, так как часто в "модель" ее пишут.

Answer 4

[Дмитрий Евграфович]

Тоже столкнулся с таким. Есть мнение, что модели возвращают потому, что в них уже можно прописать все необходимое для вывода данных, равно как и спрятать лишние поля, а также преобразовать/добавить недостающие атрибуты. Но наличие метода save() за пределами репозитория смущает. На данный момент пришел к тому, что репозиторий у меня преобразует модели в сущности (самопальными трансформерами наподобие fractal.thephpleague.com) перед тем, как отдать их, но с логикой сохранения внутри репозитория пока не пришел к конечному варианту - часто в проекте требуется не просто сохранить строку в бд в одну таблицу, а сделать гораздо более сложные вещи и вся эта логика завязана именно на процесс сохранения, поэтому не вижу способа вынести эту логику куда-то из репозитория. Но такие вещи, как return session()->flash() в примере по вашей ссылке, считаю лучше на уровне выше генерировать в зависимости от отданных репозиторием данных, они тут вообще никаким местом.

Вообще сам пока ищу наиболее удобный вариант построения приложений (засматриваюсь на гексагональную архитектуру), но применить что-то глобальное на проекте, которым занимаюсь уже год и который разрабатывался с 2014 года просто не могу. Поэтому рассматривайте мои измышления лишь как рассуждения человека, столкнувшегося с этой же проблемой и находящемся на том же пути.

Comments

[index0h]

Дмитрий Евграфович
> Вообще сам пока ищу наиболее удобный вариант построения приложений
Посмотрите Symfony+Doctrine

[Дмитрий Евграфович]

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