Комментарии 28
orm это всегда оверхэд по памяти, потому к его использованию стоит подходить грамотно. Если у вас очень большие выборки, и количество объектов в выборке вырастает до over9000, то логично этот кусок реализовать с применением dbal, снизив таким образом нагрузку и потребление памяти. Но для большинства задач orm довольно удобно использовать.
По поводу неоднозначности ленивой загрузки полей, раскройте ваше утверждение. Немного непонятно что тут неоднозначного. Остальные перечисленные недостатки в doctrine 2 не встречаются.
По поводу неоднозначности ленивой загрузки полей, раскройте ваше утверждение. Немного непонятно что тут неоднозначного. Остальные перечисленные недостатки в doctrine 2 не встречаются.
я бы так не делал ). Была такая ситуация, в select() перечислил только необходимые поля (выборка ~150 записей), через несколько дней появилась необходимость вывести в шаблоне еще одно поле, про select к этому времени успешно забыл, но оно само заработало, доктрина не ругнулась, что поля нет, а тихо сходила в базу за ним… 150 раз ) поскольку база девеловская, без нагрузки, на глаз это почти не заметно, увидел случайно в профайлере.
Ну так никто вас и не просит так делать. Почему-то пользователи hibernate не особо переживают о присутствии данной фичи.
На самом деле есть вполне понятные кейсы, когда подобное стоит использовать. Скажем у вас в базе хранится какой-то блоб, который вы хотите обработать, и вам дешевле будет сделать 500 запросов в базу чем загрузить все 500 блобов и обрабатывать их, особенно когда обработка блоба занимает какое-то время.
На самом деле есть вполне понятные кейсы, когда подобное стоит использовать. Скажем у вас в базе хранится какой-то блоб, который вы хотите обработать, и вам дешевле будет сделать 500 запросов в базу чем загрузить все 500 блобов и обрабатывать их, особенно когда обработка блоба занимает какое-то время.
смущает тихая ленивость, которая скрывает ошибки, этого же можно добиться используя явный метод вроде loadText()
А зачем завязывать логику работы с данными на то, как мы получаем эти данные? Подойдите к вопросу с другой стороны, предположим что у нас кейс, описанный мною чуть выше. С ходом времени растет нагрузка, и системе не хватает памяти, или кеширование запросов работает неэффективно, и мы просто в select прописываем выборку не всего объекта, а только нескольких полей, тем самым снижаем нагрузку, уменьшаем потребление памяти и все хорошо, а логику не трогаем.
В пхп есть возможность юзать функции .Net из C#. А там есть такое чудо, как entity framework. работал на пхп с доктриной 2. Энтайти мне нравится больше.
Юзаем Kohana и ее родную ORM
А что насчет «Юзаю доктрину и не доволен»?
Однобокий у вас опрос. Есть еще очень популярные варианты — как yii/laravel/kohana/phalcon/propel, а еще нет варианта с велосипедом
В доктрине второй есть куча фич, но столько же недостатков и багов. Например по date нельзя делать primary индекс. Просто потому что разработчики отказались принять PR, который в одну строку фиксит этот баг. Я полтора часа провозился подключая свой DateTime, c __toString, но к сожалению так и не получилось.
Далее например строим запрос с помощью qb — потом он разбирается. Спрашивается зачем?
Однобокий у вас опрос. Есть еще очень популярные варианты — как yii/laravel/kohana/phalcon/propel, а еще нет варианта с велосипедом
В доктрине второй есть куча фич, но столько же недостатков и багов. Например по date нельзя делать primary индекс. Просто потому что разработчики отказались принять PR, который в одну строку фиксит этот баг. Я полтора часа провозился подключая свой DateTime, c __toString, но к сожалению так и не получилось.
Далее например строим запрос с помощью qb — потом он разбирается. Спрашивается зачем?
Есть еще очень популярные варианты — как yii/laravel/kohana/phalcon/propel, — последний вариант
а еще нет варианта с велосипедом — второй вариант
а еще нет варианта с велосипедом — второй вариант
Далее например строим запрос с помощью qb — потом он разбирается. Спрашивается зачем?— если запрос может быть гибким, поиск например, по многим полям в разных комбинациях.
На мой взгляд, нельзя однозначно говорить о том, хорошая штука ORM или вредная. Есть плюсы и есть минусы. Любая техника и абстракция призвана помогать программисту, ускорять и облегчать его работу, работу его команды, а так же его приемников. Этот подход, безусловно, имеет право на жизнь в открытых проектах, фреймворках и CMS, в первую очередь потому, что освобождает от привязки к конкретной СУБД.
Однако, на практике не всегда всё так гладко, как в теории. Моя дружба с ORM и другими query-билдерами была недолгой. Причина была в том, что самописные ORM и билдеры сильно завязаны на ведущего разработчика бекенда, и после его ухода, бекенд потихоньку умирал и обрастал костылями, это было печальное зрелище. Потом была Доктрина 2. Изначально показавшись красивой и мощной, она оказалась довльно сложна для понимания и громоздка, и иногда ее использование в простых проектах смахивало на инверсию абстракции (помимо SQL нужно знать еще DQL и особенности его работы, всякий «annotation mapping» и т.д.) и нередко возникало ощущение лишней, избыточной работы, особенно когда приходилось искать и курить маны в поисках решения задачи, которую можно за минуту решить модификацией запроса в базу.
Позже я перешел на узкоспециализированные проекты, в которых вся модель данных заключена в СУБД (реализована через хранимые функции, триггеры и события, и имеются готовые представления для отображения на страницах сайта). Таким образом, сущность «сайт» перестала быть ключевой и стала лишь отражением информационной системы, php стал выполнять роль шаблонизатора html и формирователя json из данных, полученных из кэша или из бд, а позже был заменен другой платформой. Не думаю, что ORM здесь сыграл бы положительную роль и помог бы как-то облегчить труд программистов.
Однако, на практике не всегда всё так гладко, как в теории. Моя дружба с ORM и другими query-билдерами была недолгой. Причина была в том, что самописные ORM и билдеры сильно завязаны на ведущего разработчика бекенда, и после его ухода, бекенд потихоньку умирал и обрастал костылями, это было печальное зрелище. Потом была Доктрина 2. Изначально показавшись красивой и мощной, она оказалась довльно сложна для понимания и громоздка, и иногда ее использование в простых проектах смахивало на инверсию абстракции (помимо SQL нужно знать еще DQL и особенности его работы, всякий «annotation mapping» и т.д.) и нередко возникало ощущение лишней, избыточной работы, особенно когда приходилось искать и курить маны в поисках решения задачи, которую можно за минуту решить модификацией запроса в базу.
Позже я перешел на узкоспециализированные проекты, в которых вся модель данных заключена в СУБД (реализована через хранимые функции, триггеры и события, и имеются готовые представления для отображения на страницах сайта). Таким образом, сущность «сайт» перестала быть ключевой и стала лишь отражением информационной системы, php стал выполнять роль шаблонизатора html и формирователя json из данных, полученных из кэша или из бд, а позже был заменен другой платформой. Не думаю, что ORM здесь сыграл бы положительную роль и помог бы как-то облегчить труд программистов.
Использую фреймворк Kohana, ORM Jelly. Шустрый, и гибкий. Особых проблем с последней версией не испытывал, Есть возможность получить raw данные из запроса ORM, без использования моделей. Это в случае экономии памяти и производительности, когда не нужно использовать гетеры и сетеры модели.
Я не люблю ORM, я за PDO наверное я не… ;)
как выше сказал Stdit, применение ORM специфично и покрывает большинство простых бизнес задач. Однако, когда ты начинаешь использовать специфичные запросы или сталкиваешься с нагрузкой — то эта лишняя абстракция, лишний код который тратит ресурсы.
Лично я за правильное ООП, где должен быть DataObject. И пусть в нем маппинг не автоматизированный, но он прозрачен для программиста и при необходимости данный маппинг можно правильно с оптимизировать, а не гадать на кофейной гущи ORM. И пусть такие товарищи, как Fesor сколь угодно кричат, что зло, а что добро, но я последние пять-семь лет больше занимаюсь переделыванием и оптимизацией чужого говнокода, про архитектуру которого и не задумывались, где можно было написать по уму, используя всего лишь треть нормальных запросов…
Бл. наболело. ;(
Лично я за правильное ООП, где должен быть DataObject. И пусть в нем маппинг не автоматизированный, но он прозрачен для программиста и при необходимости данный маппинг можно правильно с оптимизировать, а не гадать на кофейной гущи ORM. И пусть такие товарищи, как Fesor сколь угодно кричат, что зло, а что добро, но я последние пять-семь лет больше занимаюсь переделыванием и оптимизацией чужого говнокода, про архитектуру которого и не задумывались, где можно было написать по уму, используя всего лишь треть нормальных запросов…
Бл. наболело. ;(
Абсолютно согласен по всему сказанному. И особенно
PS:
но я последние пять-семь лет больше занимаюсь переделыванием и оптимизацией чужого говнокода, про архитектуру которого и не задумывались, где можно было написать по уму, используя всего лишь треть нормальных запросов…
PS:
Я не люблю ORM,это не значит не использовать
Боюсь если эти же люди, проекты которых вы переделываете, будут закладывать еще и оптимизации какие-то, то лучше не станет. Большая часть проблем с архитектурой приложений, которые я видел (если она вообще закладывалась) как раз таки и вызваны попытками оптимизировать что-то до того, как в этом появляется необходимость. Причем делается это без оглядки на будущее, что в итоге вызывает довольно большие временные затраты на поддержку и расширение функционала.
согласен
Использую Doctrine 1 на работе и 2 в своих поделках — доволен, особенно второй.
Но вообще не стоит забывать, что это паттерн, а опрос, судя по всему, об универсальных реализациях этого паттерна. Никто не запрещает использовать маппинг реляционных данных на объекты без монстрообразных библиотек — сделайте SQL-запрос, написанный ручками, хоть через mysql_* и проинициализируйте результатом объект (конструктором, сеттерами, паблик поля, рефлексией — не суть, как вам нравится) или коллекцию — это тоже ORM. Основной оверхид идёт через попытки универсального декларативного описания схемы маппинга — отказываемся от этого, используем захардкоженный императивный маппинг и имеем минимум оверхида, да и сложность его обычно O(N), где N число строк в ответе, что по процу, что по памяти. Doctrine 1 же при использовании иерархической гидрации навскидку имеет сложность O(N^M), где M — число таблиц в запросе.
Но вообще не стоит забывать, что это паттерн, а опрос, судя по всему, об универсальных реализациях этого паттерна. Никто не запрещает использовать маппинг реляционных данных на объекты без монстрообразных библиотек — сделайте SQL-запрос, написанный ручками, хоть через mysql_* и проинициализируйте результатом объект (конструктором, сеттерами, паблик поля, рефлексией — не суть, как вам нравится) или коллекцию — это тоже ORM. Основной оверхид идёт через попытки универсального декларативного описания схемы маппинга — отказываемся от этого, используем захардкоженный императивный маппинг и имеем минимум оверхида, да и сложность его обычно O(N), где N число строк в ответе, что по процу, что по памяти. Doctrine 1 же при использовании иерархической гидрации навскидку имеет сложность O(N^M), где M — число таблиц в запросе.
Propel в Silex, странно что нет варианта «Использую стороннюю ORM».
Использую Jelly в Kohana
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ORM в PHP быть или не быть?