NotORM

Обсуждаем, как правильно строить приложения
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

NotORM

Сообщение anton_z »

Давно хотел обсудить одну тему, видео Александра Макарова про переусложение многих проектов подтолкнуло.
Кто и как относится к движению NotORM?
Оно утверждает, что ORM - антипаттерн.
http://www.yegor256.com/2014/12/01/orm- ... ttern.html
http://seldo.com/weblog/2011/08/11/orm_ ... ntipattern

Типа, все работает медленно, все абстракции над SQL и реляционными данными протекают, главным образом из-за производительности и программирования хоть и в терминах объектов, но с оглядкой на БД.

Предлагаются даже альтернативные библиотеки:

http://lessql.net
http://www.notorm.com

По англоязычным блогам также гуляет мнение, что ORM не стоит использовать вообще. Ни в маленьких, ни в больших проектах.
Маленькие - ненужное переусложение
Большие - проблемы с производительностью и проблемы использования нативных db-фич.

Кто-нибудь использовал подобные библиотеки в реальных проектах?
Каково ваше мнение на этот счет? Может я отстал от мэйнстрима и ORM давно победил?
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: NotORM

Сообщение samdark »

Делал проекты ещё до Yii с немного подпиленной DbSimple Котерова. В принципе, нормально было.

Если увлекаться DDD, так и так репозитории делать. А что там будет в них — SQL, AR или какая-нибудь Doctrine — не важно. Слышал негатив не так давно как раз про DDD + Doctrine.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: NotORM

Сообщение zelenin »

doctrine практически идеально ложится на ddd (использую прямо сейчас в текущем проекте), но чрезмерно тяжелая, переусложененная, собравшая внутри себя все худшие практики.
Написал для себя легкую ORM, состоящую из квери-билдера, генерящего sql, маппера, с помощью вручную написанных мапперов, маппящих БД к сущностям, и поверх всего этого entity manager (mapper + identity map + UoW).
Считаю, что такие решения лучше всего подходят - самописный маппинг, пяток классов, нет оверхеда за счет покрытия тысячи ненужных кейсов.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: NotORM

Сообщение zelenin »

anton_z писал(а): 2017.05.11, 13:07 http://lessql.net
http://www.notorm.com
это квери билдеры. все равно же маппинги писать.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: NotORM

Сообщение anton_z »

Я как раз про нужность DDD. С ним пытаемся представить что у нас в коде конечное состояние данных приложения. Но на самом деле это не так. OrRM пытается решать эту проблему с помощью ленивой загрузки, проксирования. А может это неправильная идея? Конечное состояние у нас в бд лежит и все. Приложение - это интерфкйс к нему.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: NotORM

Сообщение samdark »

Что именно имеется ввиду под "конечным" состоянием?
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: NotORM

Сообщение anton_z »

Под конечным состоянием имелись ввиду актуальные данные с которыми работает приложение.
Соответсвенно, в приложении должны быть SQL speaking objects и все.
А то получается, что у нас есть одно состояние в БД и другое - в приложении.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: NotORM

Сообщение anton_z »

zelenin писал(а): 2017.05.11, 19:31 это квери билдеры. все равно же маппинги писать.
В сложных случаях, да, маппинги нужны.
А если не абстрагироваться от БД, если суть приложения в работе с БД с парой условий: пришла dto в сервис - взяли билдер и сделали запрос в базу. Ни сущностей, ни репозиториев, ни AR. Просто шлюз к данным. Причем нестатический.
Последний раз редактировалось anton_z 2017.05.12, 04:31, всего редактировалось 1 раз.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: NotORM

Сообщение anton_z »

Да и дело даже не в конкретной реализации (Doctrine), а в самой идее существования объектов-сущностей, которые потом маппятся в базу - типа это все равно "глаз на ж*пу". Я сам не сторонник таких ультра-заявлений. Просто хочу понять, почему они появились, разделяет ли кто-нибудь их
http://www.yegor256.com/2014/12/01/orm- ... ttern.html
Статья программиста из Калифорнии.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: NotORM

Сообщение zelenin »

anton_z писал(а): 2017.05.12, 02:39если суть приложения в работе с БД с парой условий: пришла dto в сервис - взяли билдер и сделали запрос в базу. Ни сущностей, ни репозиториев, ни AR. Просто шлюз к данным
ну вот опять на каком-то выборочном кейсе пытаешься построить принцип.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: NotORM

Сообщение zelenin »

anton_z писал(а): 2017.05.12, 02:43 Да и дело даже не в конкретной реализации (Doctrine), а в самой идее существования объектов-сущностей, которые потом маппятся в базу - типа это все равно "глаз на ж*пу"
почему? у тебя все так работает так или иначе.
anton_z писал(а): 2017.05.12, 02:43http://www.yegor256.com/2014/12/01/orm- ... ttern.html
Статья программиста из Калифорнии.
Егор славится своими резкими заявляениями, которые вызывают холивары, но обычно его мнения маргинализированы по сравнению с мейнстримным.
Конкретно по этой статье: ты сам ее прочел? Причины, по которой он считает орм антипаттерном, видишь? Они тебя устраивают?
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: NotORM

Сообщение anton_z »


The main point is that ORM, instead of encapsulating database interaction inside an object, extracts it away, literally tearing a solid and cohesive living organism apart. One part of the object keeps the data while another one, implemented inside the ORM engine (session factory), knows how to deal with this data and transfers it to the relational database.
Насколько я понял, его не устраивает, что сущность не знает как себя сохранять в БД, как ее состояние переводится в данные в базе. По его словам, ORM разрывает объект на две части - одна хранит состояние, другая это состояние сохраняет/достает из БД.

По мне это две обязанности, и их бы желательно разделить (как показал опыт применения AR).
Я потому и спрашиваю, что мне это странным показалось. До этого про Егора не слышал. Получается его идеи неприменимы на практике?
Последний раз редактировалось anton_z 2017.05.12, 08:48, всего редактировалось 3 раза.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: NotORM

Сообщение anton_z »

zelenin писал(а): 2017.05.12, 07:49 ну вот опять на каком-то выборочном кейсе пытаешься построить принцип.
Все все, я понял. Есть общая методология - проверенная и опробованная, хорошо описанная в книгах - DDD.
Если с ней не получается - значит неправильно применяю и надо понять/узнать как правильно.
Если для конкретной задачи хорошо подходит своя конкретная придумка - можно делать по ней. Самостоятельно строить методологии - неблагодарное дело.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: NotORM

Сообщение zelenin »

я согласен с тобой, не согласен с Егором.
Самый важный кейс ORM - абстрагировать сущность от хранилища. А он именно этот кейс называет ненужным. Ну да, если тебе от лопаты не нужно, чтобы она копала, то вероятно, тебе и лопата не нужна.
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: NotORM

Сообщение ElisDN »

anton_z писал(а): 2017.05.12, 08:21 Все все, я понял. Есть общая методология - проверенная и опробованная, хорошо описанная в книгах - DDD.
Причём тут опять DDD? Есть линейный код, есть процедурное программирование, есть функциональное, есть объектно-ориентированное.
anton_z писал(а): А если не абстрагироваться от БД, если суть приложения в работе с БД с парой условий: пришла dto в сервис - взяли билдер и сделали запрос в базу. Ни сущностей, ни репозиториев, ни AR. Просто шлюз к данным. Причем нестатический.
Если нужна просто веб-морда к БД, то не только ORM не нужно, но и само приложение можно вообще не программировать. Поставьте заказчику PhpMyAdmin или MS Access как шлюз к данным и всё. А вместо REST API настройте права на таблицы и включите внешний доступ к SQL-серверу.
anton_z писал(а): Конечное состояние у нас в бд лежит и все. Приложение - это интерфейс к нему.
Если у нас просто "данные - интерфейс", то ничего не нужно. PhpMyAdmin, ActiveRecord и $mysqli->query() заходят идеально.

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

Была когда-то мода всё приложение на вьюшках, хранимках и триггерах прямо в БД программировать. Только волосы у тех программитсов быстро седели.
anton_z писал(а): Типа, все работает медленно
Если надо быстро, то пишите на Java/Go/C/ассемблере.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: NotORM

Сообщение anton_z »

ElisDN писал(а): 2017.05.12, 09:39 Если надо быстро, то пишите на Java/Go/C/ассемблере.
Так быстро не надо) Надо, чтобы в 200-300 мс открытие страницы укладывалось. С PHP7 и doctrine пока укладываюсь.

Дмитрий, что по этой статье можете сказать? (С zelenin'ым выше обсуждали)

http://www.yegor256.com/2014/12/01/orm- ... ttern.html
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: NotORM

Сообщение anton_z »

ElisDN писал(а): 2017.05.12, 09:39
А если "данные - промежуточная логика - интерфейс", то уже надо эту логику разрабатывать. Если куча кода не влезает в голову, то группируем по процедурам и функциям. Если куча процедур не влезают, то группируем по объектам. Если куча объектов не влезает, то по модулям.
Если куча модулей не влезает - по микросервисам)
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: NotORM

Сообщение samdark »

Понял про "конечное" состояние. Мысли возникают потому как PHP умирает и в большинстве проектов объект или объекты, заворачивающие данные приложения не успевают прожить и секунды. Обидно и оверхед.

Другое дело, например, Android или J2EE или golang — приложение не умирает, в память можно напихать объектов, работать с ними и иногда их персистить или вынимать из хранилища. Именно из таких неумирающих сред и вылезли все паттерны, ORM (привет Hibernate от Doctrine) и т.д.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: NotORM

Сообщение zelenin »

samdark писал(а): 2017.05.12, 12:06Другое дело, например, Android или J2EE или golang — приложение не умирает, в память можно напихать объектов, работать с ними и иногда их персистить или вынимать из хранилища. Именно из таких неумирающих сред и вылезли все паттерны, ORM (привет Hibernate от Doctrine) и т.д.
скорее некоторые реализации. То есть да, модель доктрины слизана с hibernate, поэтому в ней присутствует UoW и IMap, что в PHP редко может пригодиться. Но сам паттерн ORM - обычная ООП вещь.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: NotORM

Сообщение samdark »

В статье Егор схитрил. Пример из Hibernate и он намеренно оставляет объекты голыми, хотя это уже к ORM отношения не имеет. То есть пункт про то, что объект анемичен не засчитывается.

Пункт про протекание SQL в верхние слои — да, без репозитория будет течь, да и с ним может. Засчитывается.

Пункт про тестирование — не согласен. Никакой разницы не будет, если интеграционные тесты писать. И будет разница в положительную сторону, если писать юнит на сами объекты.

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