Если ли смысл в ОРМ для моего случая?

Question

[magary4]

Есть ли порог когда использование ОРМ становится неоправданым/оправданым? Где он?

У меня в приложении есть модуль который работает с бд Solr. Структура довольно простая. Каждый документ содержит около 30 полей. Каждый документ может имеет поле parent в котором сохранен ид-родителя, дальше ид-прародителя, дальше прапрародителя итд.
Т.е. иногда достается только один документ, а в другом случае еще и все предки.
Данные в бд импортируются через терминал и не изменяются никогда. Т.е. приложение работает с бд в режиме read-only
В данный момент работает так:
$doc->title= $result[title]
$doc->inStock= $result[in_stock]

Итд. Иногда какая-то дополнительная трансформация.

Есть ли смысл в ОРМ?

Answer 1

[Сергей Протько]

Есть ли порог когда использование ОРМ становится неоправданым/оправданым? Где он?

ORM-ки нужня для одного конкретного типа систем - OLTP (On-line Transaction Processing)

У меня в приложении есть модуль который работает с бд Solr

У вас есть документы, в документно ориентированных базах данных нет связей. Потому вам нужен Object Document Manager а не Object Relational Mapper.

Каждый документ может имеет поле parent в котором сохранен ид-родителя, дальше ид-прародителя, дальше прапрародителя итд.

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

бд в режиме read-only

Тогда точно не нужна ORM/ODM.

Итд. Иногда какая-то дополнительная трансформация.

Но это же трансформация на уровне формирования результата выборки, так? Если так - то это опять же не та проблема.

Comments

[magary4]

>>> Но это же трансформация на уровне формирования результата выборки, так? Если так - то это опять же не та проблема

Сергей, как всегда спасибо вам за дельный развернутый совет.

Если ОРМ не нужна как я и предполагал, то надо ли применять какие-то другие "умные" классы или паттерны?

Репозиторий достает данные и билдит DocumentObject?

[magary4]

Я понимаю что связи это не гуд. Но как без них для моей задачи?

[Сергей Протько]

magary4: просто любым удобным способом достаете что надо, просто выносите это в отдельный какой объект у которого только эта задача и больше никаких других задач нет. Так мы прячем это и выполняем задачу.

Answer 2

[index0h]

Есть ли порог когда использование ОРМ становится неоправданым/оправданым? Где он?

Чаще всего он становится неоправданным из-за слишком высоких накладных расходов.
Пример:
User MANY_TO_MANY Group
User MANY_TO_MANY Category

Нужно найти все категории, по заданному списку групп пользователей. В случае Doctrine ORM вам придется загрузить список груп, дальше циклом пройтись по всем пользователям (если загрузка ленивая - это куча запросов), дальше уже по всем пользователям пробежаться и вытянуть все категории, плюс убрать дубликаты. Тут лучше plain sql, или query builder, как вам больше нравится.

В случае же когда, накладные расходы не высоки И ORM будет более удобной - стоит юзать ORM. Например: у вас уже есть загруженный пользователь, хотите достать все его группы. В случае Doctrine ORM это может выглядеть как: $user->getGroups().

Comments

[magary4]

>> Например: у вас уже есть загруженный пользователь, хотите достать все его группы. В случае Doctrine ORM это может выглядеть как: $user->getGroups()

А как это спроэктировать без орм?

Репозиторий делает запрос в бд по ИД. Маппит результат в UserObject. После В UserObject есть метод getGroups (для моего случая getParentsChain) который обращается к репозиторию и достает вторую порцию данных и снова маппит их.
Или как?

[Сергей Протько]

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

[Сергей Протько]

Ну а для выборок как вы описали и так есть замечательные вещи - такие как SQL (а в доктрине еще и DQL если хочется сохранить абстракцию от базы данных).

[magary4]

Сергей Протько: да но это очень типичная задача. Программер начинает писать проект на симфони - видит в документации доктрину, описывает свои энтити. Сначала обычный crud но очень скоро все усложняется группами и категориями
Т.е. использовать ОРМ изначально ошибка как я вас понял?
Мало проектов остаются чистым OLTP

[Сергей Протько]

magary4: пока у вас нет OLTP - вам не нужна ORM. Если вам нужно сделать репорт или просто выдать вот этот список категорий - то вам хватит SQL (в случае реляционных баз данных, в случае solr хватит средств solr-а).

Но давайте придумаем такой пример. Допустим вам нужно выбрать все категории так как предложил index0h и потом сделать с каждой что-то. Это уже подходит под задачи OLTP, просто надо разделить все на два этапа:

1) мы выбираем id-ки категорий при помощи обычного SQL с джойнами и т.д.
2) мы грузим категории по отдельности (можно по нескольку штук через where in но это уже оптимизации) и каждая операция с категорией будет расцениваться как маленькая транзакция. Вот в этом ключе ORM-ки оправданы, особенно если мы делаем что-то сложное и нам удобнее это описать в виде взаимодействия объектов.

p.s. рекомендую вам глянуть: https://www.youtube.com/watch?v=rzGeNYC3oz0

[Сергей Протько]

magary4:

Программер начинает писать проект на симфони - видит в документации доктрину, описывает свои энтити. Сначала обычный crud но очень скоро все усложняется группами и категориями

Есть такая штука - культ карго. Вот вы сейчас описали это поведение человека.

Т.е. использовать ОРМ изначально ошибка как я вас понял?

Нет конечно, не стоит в крайности впадать. Просто нужно понимать что когда юзать. Например возьмем ту же Doctrine и какой-нибудь простенький проект. Например - мааахонький инстаграмчик. Пользователи постят фотки. К фоткам можно лепить лайки и комменты.

Задачи аля:

- добавить фотку
- добавить лайк
- добавить коммент

это все сводится к OLTP поскольку у нас задействовано малое количество объектов. Есть еще такой термин как агрегат сущностей, которым описывают все объекты учавствующие в бизнес транзакции. И вот ORM-ки делают это дико удобным.

Но проект развивается и вот в нашем инстраграме нужно уже отображать:

- список фоток всех друзей
- на главной странице надо отображать трендовые фотки - по одной из каждой страны
- примешивать в трендинг фотки проплаченный контент (мы ж хотим зарабатывать?)

И все это - не является задачами из разряда OLTP но доктрина предоставляет нам свой query builder и если нам не нужны потом объекты - мы можем сразу гидрировать результаты в массивчик. А можно вообще свои гидраторы сделать. А можно даже так:

select new SomeResultDTO(u.name, p.image, c.countryFlag) from Pictures WHERE ...

то есть сразу смэпить все на какие-то промежуточные объекты которые содержат только то что нужно.

Но вот это уже не является частью непосредственно ORM - это чуть другой уровень.

[magary4]

Сергей Протько: а если как в моей задачи - достать предков. Это ведь тоже можно сделать по отдельности и эта операция будет расцениваться как маленькая транзакция? Т.е запахло oltp?

[Сергей Протько]

magary4: нет, это запахно не оптимальным способом работы с данными. Если вам нужно вытащить 10 связанных данных из базы лучше сделать это одним запросом. Я не очень то работал с solr, знаю что в elasticsearch есть nested documents, и можно все запихнуть в один большой документ и загружать его частично одним запросом. Но как эффективно хранить деревья в solr я не знаю - не приходилось с таким сталкиваться пока.

На вскидку если запихнуть все в большой документ не очень удобно - можно воспользоваться materialized path, и таким образом достать что нужно. Но тут думать надо и пробовать.

[magary4]

Сергей Протько: >>> p.s. рекомендую вам глянуть: https://www.youtube.com/watch?v=rzGeNYC3oz0

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

[magary4]

Сергей Протько: если можно то вот еще вопрос назрел ))

если отбросить тему ОРМ
на одной странице надо отобразить простой документ, а на другой его же но внизу список групп

как это спроектировать лучше ?
можно $user->getGroups().
а можно сделать 2 конструктора
User::create()
User::createWithGroups()

еще слышал про паттерн по-моему "репрезентация" но не уверен так как ничего не нахожу
чтоб один и тот же обьект иметь возможность получить в нескольких вариантах

[index0h]

magary4 Используйте статику только в исключительных ситуациях, когда по другому вот никак. Иначе вы получаете неявную зависимость.

> чтоб один и тот же обьект иметь возможность получить в нескольких вариантах
Зависит от ситуации конечно, но конкретно в вашем примере стоит использовать: addGroup/removeGroup/getGroups методы + настройки рилейшнов, что предлагает доктрина.

[Сергей Протько]

magary4: адекватного списка пока нет. Постараюсь собрать, а то то что сходу нагуглил так себе.

Есть php-must-watch ( https://github.com/phptodayorg/php-must-watch ) но такое в общем а не про симфони. Что тоже полезно в принципе.

как это спроектировать лучше ?

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

а можно сделать 2 конструктора

Вам же отобразить нужно, то есть какие конструкторы? Вы уже готовые сущности получаете.

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

Ну то есть смысл в том что-бы вы понимали зачем вы что-то делаете а не как, ибо как - вопрос простой. Вы сейчас сильно загоняетесь по весьма второстепенным вопросам.

еще слышал про паттерн по-моему "репрезентация" но не уверен так как ничего не нахожу
чтоб один и тот же обьект иметь возможность получить в нескольких вариантах

Это подразумевает создание новых объектов, возможно DTO, которые будут хранить кусок состояния. Тем самым мы снижаем связанность и можем формировать это представление как захотим.

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

в вашем примере стоит использовать: addGroup/removeGroup/getGroups методы + настройки рилейшнов, что предлагает доктрина.

та же тема что и с геттерами/сеттерами. Если оно оправдано в терминах бизнес логики - то да, согшалусь. Но getGroups например ни в коем случае не должен вернуть ArrayCollection.

[Сергей Протько]

magary4: а паттерн называется Presenter. Во всяком случае нагуглить так выдается в контексте PHP.

p.s. Есть товаристчи которые пишут на Laravel и постоянно извращают паттерны. Файдеры у них репозитории, сервис локатор = фасад и т.д. Ну и там вот презентера впилили, хотя тут хотя бы минимально по смыслу подходит.

[magary4]

>>>автору они в этой ситуации не нужны, согласен. Я сейчас почти все время делаю все на билдерах, и мне дико нравится.

ну так а для моей задачи это правильно будет сделать на билдерах?
один метод билдера через репозиторий делает запрос и возвращает простой обьект ( User )
второй делает 2 запроса через репозиторий и возвращает более сложный обьект ( User с загруженными группами )

[index0h]

Сергей Протько
> Но getGroups например ни в коем случае не должен вернуть ArrayCollection.
Почему же? Вполне норм практика. В конструкторе создаем $this->groups = new ArrayCollection();
Сам геттер объявляем как
public function getGroups() : Collection
Согласен, тут есть нюанс, что при гидрации зависимостей доктрина их заменит на PersistCollection, про это нужно помнить. Но в остальном - не вижу проблем, не хотите юзать коллекции - не проблема, вызываем ->toArray() и все счастливы.

> Я сейчас почти все время делаю все на билдерах, и мне дико нравится.
Как вы покрываете тестами код, который использует зависимости со статикой? Я сейчас на проекте, в котором unit тестами с моками зависимостей покрывается практически все (98%), а со статикой возникают проблемы, phpunit это дело не мокает. Из за этого на проекте введено соглашение о запрете использования статических вызовов (кроме тех, что предлагает PHP, их мы не тестируем).

[Сергей Протько]

index0h:

про это нужно помнить

Когда нужно о чем-то помнить, причем о чем-то, что не относится к делу (ну мол вас не должно ж парить что там) - это является прямым нарушением инкапсуляции. Нафиг внешнему миру знать о коллекциях.

То что это в мире симфони норм практика я верю - но в мире доктрины это плохая практика.

Как вы покрываете тестами код, который использует зависимости со статикой?

Легко и просто. У меня ж нет состояния статического, это просто методы фабрики, не нужно их мокать. Вот и весь секрет. Проблемы это когда через статику доступ к какому-то состоянию организован, например "фалады" ларавелевские или Yii (весь Yii).

[index0h]

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

> То что это в мире симфони норм практика я верю - но в мире доктрины это плохая практика.
Можно по подробнее, почему?

> У меня ж нет состояния статического, это просто методы фабрики, не нужно их мокать.
Вариант. Но не лучше ли в таком случае сделать state-less сервис, который будет уметь то же самое, но передавать его как явную зависимость?