Комментарии 72
PHP идет по стопам Java, наступая на те же грабли.
Да, очень положе на JPA: docs.jboss.org/hibernate/stable/annotations/reference/en/html/entity.html#d0e1177
В Groovy, Ruby, Python — есть возможности мета-программирования и там действительно можно сделать лучший API. В Java это достигается с помощью аннотаций — где там грабли-то?
В Groovy, Ruby, Python — есть возможности мета-программирования и там действительно можно сделать лучший API. В Java это достигается с помощью аннотаций — где там грабли-то?
Ну так Хибернейт совсем неслабая штука.
А о каких граблях идет речь?
А о каких граблях идет речь?
Сам недавно познал разбор phpDoc'a через рефлексию…
самого мощного на сегодняшний день ORM-фреймворка для PHP: Doctrine
хорошо завернул. автор, какие еще орм-фреймворки ты знаешь?
хорошо завернул. автор, какие еще орм-фреймворки ты знаешь?
Propel?
Оу, я прочел ваши мысли еще до того как вы написали этот комментарий и сразу начал писать ответ :)
Если знаете ORM для PHP получше Doctrine — советуйте и аргументируйте, буду очень признателен, т. к. у самого манечка с пристрастием копаться в различных библиотеках в поисках наиболее архитектурно правильных и красивых решений.
Лично мне очень нравятся идеи RedBean (вот реализацию как по мне можно было бы сделать покрасивее), хотя это не совсем ORM, и очень нравится Recess php framework (Это вообще MVC фреймворк, извиняюсь за оффтоп), но не своим ORM, я предвкушаю, что на нем получается очень высокая скорость разработки.
А вообще мне нравится Django (RoR конечно же тоже нравится, но Django нравится больше потому что: native механизм adminpages, шаблоны проще (хотя мой идеал шаблонов далек и от джанги), нет привязки к Javascript библиотекам (ура! Да здравствует JQuery!), python популярнее и на данный момент если не ошибаюсь — быстрее (синтаксис ruby честно говоря больше нравится чем python)
Ноооо… что-то меня понесло… в общем, вот такое у меня мировоззрение веб-разработчика, а мы сейчас говорим об ORM для PHP :)
Если знаете ORM для PHP получше Doctrine — советуйте и аргументируйте, буду очень признателен, т. к. у самого манечка с пристрастием копаться в различных библиотеках в поисках наиболее архитектурно правильных и красивых решений.
Лично мне очень нравятся идеи RedBean (вот реализацию как по мне можно было бы сделать покрасивее), хотя это не совсем ORM, и очень нравится Recess php framework (Это вообще MVC фреймворк, извиняюсь за оффтоп), но не своим ORM, я предвкушаю, что на нем получается очень высокая скорость разработки.
А вообще мне нравится Django (RoR конечно же тоже нравится, но Django нравится больше потому что: native механизм adminpages, шаблоны проще (хотя мой идеал шаблонов далек и от джанги), нет привязки к Javascript библиотекам (ура! Да здравствует JQuery!), python популярнее и на данный момент если не ошибаюсь — быстрее (синтаксис ruby честно говоря больше нравится чем python)
Ноооо… что-то меня понесло… в общем, вот такое у меня мировоззрение веб-разработчика, а мы сейчас говорим об ORM для PHP :)
Вот что меня смущает — я не уверен, правильно ли говорить, что Doctrine — самый мощный PHP ORM. Возможно это субъективные впечатления, подкрепленные субъективными мнениями веб-разработчиков из близких мне Интернетов.
Собственно для справки: Из ORM для PHP я имел дело только с Doctrine, Propel, RedBean(если это можно сюда отнести), и ORM из Kohana Framework.
Возможно вы знаете какие-то менее популярные, но очень хорошие ORM(и близкие по идеологии) библиотеки для PHP — Welcome, делитесь! :)
Собственно для справки: Из ORM для PHP я имел дело только с Doctrine, Propel, RedBean(если это можно сюда отнести), и ORM из Kohana Framework.
Возможно вы знаете какие-то менее популярные, но очень хорошие ORM(и близкие по идеологии) библиотеки для PHP — Welcome, делитесь! :)
Что можете сказать про Propel в сравнении с Doctrine?
НЛО прилетело и опубликовало эту надпись здесь
Могу сказать что код там менее интуитивный(имхо), структура документации тоже не тек хороша(имхо) (хотя и у Doctrine совсем не шоколад), зато ее там больше чем для Doctrine 2.0 в данный момент.
Возможно кому-то Propel больше понравится в этом плане, но я не отношусь к числу этих людей.
Так же насколько я знаю, там нет возможности задавать мета-данные для меппинга в комментариях и нет поддержки YAML (а вот XML есть и там и там).
Я бы сказал отличия в основном в немного разных подходах и мелочах, но в общем можно сказать что Doctrine немного богаче в плане альтернативных способов выполнить одни и те же действия.
Возможно кому-то Propel больше понравится в этом плане, но я не отношусь к числу этих людей.
Так же насколько я знаю, там нет возможности задавать мета-данные для меппинга в комментариях и нет поддержки YAML (а вот XML есть и там и там).
Я бы сказал отличия в основном в немного разных подходах и мелочах, но в общем можно сказать что Doctrine немного богаче в плане альтернативных способов выполнить одни и те же действия.
Наверное скопом можно добавить все популярные ООП фреймворки, ну, кроме symfony ;)
Мне очень, очень нравится синтаксис join'ов и условий в CakePHP. Однако очень не нравится ужасная жиробасность CakePHP, поэтому пришлось самому накатать велосипед с почти таким же синтаксисом:
$news=$News->contain(array(
'NewsComment'=>array(
'User'=>array('fields'=>array('user_id', 'username')),
),
))->find(array(
'News.id'=>$id
));
wiki.limb-project.com/doku.php?id=limb3:ru:packages:active_record — отличная реализация паттерна ActiveRecord на PHP есть в Limb Framework.
Штука хорошая, да.
Но Doctrine поболее будет. Вот такой штуки как DQL там нет. Ну и еще нескольких штук.
Но если не нужен весь монстр Doctrine, то можно пользовать.
Но Doctrine поболее будет. Вот такой штуки как DQL там нет. Ну и еще нескольких штук.
Но если не нужен весь монстр Doctrine, то можно пользовать.
никогда не понимал смысла DQL. приведите пример, когда без него ну никак.
В том что язык запросов не зависит от СУБД, от конкретного маппинга (имен таблиц и полей в БД) ну и т.д., так как оперирует бизнес-объектами а не таблицами.
слишком расплывчато. можно конкретнее?
Хм, вроде, должно быть итак понятно… DQL оперирует с нашими классами/свойствами, а не с таблицами/колонками. А потом автоматически транслируется в нужный SQL для конкретной СУБД.
перефразирую вопрос:
зачем DQL, если всё можно сделать и без его использования, с помощью «стандартных» методов выборки?
зачем DQL, если всё можно сделать и без его использования, с помощью «стандартных» методов выборки?
а что есть «стандартные методы?» =)
так нечестно :-)
стандартные для меня методы — это методы/свойства классов, без написания каких бы то ни было запросов явном виде или произвольно взятом диалекте, производном от sql
стандартные для меня методы — это методы/свойства классов, без написания каких бы то ни было запросов явном виде или произвольно взятом диалекте, производном от sql
слишком расплывчато =)
DQL, как и SQL, можно отнести к DSL, которые удобны именно для выборки данных.
Можно пример методов выборки, которые настолько же мощны как чистый SQL?
DQL, как и SQL, можно отнести к DSL, которые удобны именно для выборки данных.
Можно пример методов выборки, которые настолько же мощны как чистый SQL?
я потому и спрашивал, что мне интересно, когда в _рядовых_ (а именно на эту нишу ориентированы ОРМ) проектах возникают задачи, которые невозможно решить более простыми и читабельными средствами (без (S|D)QL)
Ну, на счет рядовых проектов и ОРМ я с вами не согласен, но это тема для другой дискуссии.
Во-вторых, я так и не пойму, что вы считаете более простыми и читабельными средствами чем SQL, имхо, SQL как раз простой и читаемый способ.
Какие уровни абстракции обычно есть в ОРМ:
— верхний уровень работа непосредственно с объектами и их зависимостями (хорошо для организации стандартного CRUD).
— Различные билдеры для запросов (Doctrine Query Builder, Hibernate Criteria, Zend_Db_Query, Propel Criteria, etc) Это уже более мощное средство, однако все равно не так сильно как чистый SQL
— DQL/HQL уровень наиболее близкий (а соответственно наиболее функциональный) к чистому SQL.
Кроме того я не разделяю мнения что SQL/DQL/HQL менее понятны чем нативные методы, имхо, совсем наоборот. При отсутствии уровня DQL/HQL приходится использовать билдеры для абстракции от чистого sql. Хотя я лично считаю что билдеры надо использовать там где нужно именно динамически билдить запрос в зависимости от каких либо параметров (самый частый вариант — поиск по набору критериев), в стандартном же случае проще использовать DQL/HQL.
Во-вторых, я так и не пойму, что вы считаете более простыми и читабельными средствами чем SQL, имхо, SQL как раз простой и читаемый способ.
Какие уровни абстракции обычно есть в ОРМ:
— верхний уровень работа непосредственно с объектами и их зависимостями (хорошо для организации стандартного CRUD).
— Различные билдеры для запросов (Doctrine Query Builder, Hibernate Criteria, Zend_Db_Query, Propel Criteria, etc) Это уже более мощное средство, однако все равно не так сильно как чистый SQL
— DQL/HQL уровень наиболее близкий (а соответственно наиболее функциональный) к чистому SQL.
Кроме того я не разделяю мнения что SQL/DQL/HQL менее понятны чем нативные методы, имхо, совсем наоборот. При отсутствии уровня DQL/HQL приходится использовать билдеры для абстракции от чистого sql. Хотя я лично считаю что билдеры надо использовать там где нужно именно динамически билдить запрос в зависимости от каких либо параметров (самый частый вариант — поиск по набору критериев), в стандартном же случае проще использовать DQL/HQL.
НЛО прилетело и опубликовало эту надпись здесь
например, возможность использовать INDEXBY
Doctrine_Query::create()
->from('User u INDEXBY u.username')
->innerJoin('u.Groups g INDEXBY g.name');
Doctrine_Query::create()
->from('User u INDEXBY u.username')
->innerJoin('u.Groups g INDEXBY g.name');
Оптимизация, кеширование…
слишком расплывчато. как DQL связан с вопросом кеширования?
Примерно так же, как и с оптимизацией.
Например, есть таблица постов (Posts), у каждого поста есть автор (Users), ну и у пользователя профиль (Profiles).
Если я буду перебирать $posts хранящий посты в цикле и забирать по relation информацию о профиле, это породит множество запросов — равное count($posts)*2, насколько я понимаю.
При использовании DQL, я могу сразу приджойнить нужные таблицы, и все данные заберу в один запрос.
Более того, этот один запрос я смогу закэшировать, и гибко управлять временем жизни кэша конкректно по этим данным, очищать кэш в случае необходимости так же удобно. И т.д. Поправьте меня, если я где-то вру.
Единственный способ делать это иначе, как я понимаю, RawSql API — но это далеко не самый удобный способ.
Например, есть таблица постов (Posts), у каждого поста есть автор (Users), ну и у пользователя профиль (Profiles).
Если я буду перебирать $posts хранящий посты в цикле и забирать по relation информацию о профиле, это породит множество запросов — равное count($posts)*2, насколько я понимаю.
При использовании DQL, я могу сразу приджойнить нужные таблицы, и все данные заберу в один запрос.
Более того, этот один запрос я смогу закэшировать, и гибко управлять временем жизни кэша конкректно по этим данным, очищать кэш в случае необходимости так же удобно. И т.д. Поправьте меня, если я где-то вру.
Единственный способ делать это иначе, как я понимаю, RawSql API — но это далеко не самый удобный способ.
в коллекции есть загрузка по требованию связанных объектов
www.doctrine-project.org/documentation/manual/1_2/en/component-overview#collection:loading-related-records
www.doctrine-project.org/documentation/manual/1_2/en/component-overview#collection:loading-related-records
Вы про $posts->loadRelated('Users');?
Это несомненно помогает, но DQL поможет добиться большей производительности.
Опять же, как управлять временем жизни кеша при loadRelated()? Наверное, это возможно, указав общее время жизни кэша для таблицы (я правда не знаю как), но управление на уровне запросов мне кажется более надежным.
Ну а в целом — Вы правы в том, с точки зрения реализации бизнес-логики приложения, без DQL можно обойтись пожалуй всегда, ну или почти всегда.
Это несомненно помогает, но DQL поможет добиться большей производительности.
Опять же, как управлять временем жизни кеша при loadRelated()? Наверное, это возможно, указав общее время жизни кэша для таблицы (я правда не знаю как), но управление на уровне запросов мне кажется более надежным.
Ну а в целом — Вы правы в том, с точки зрения реализации бизнес-логики приложения, без DQL можно обойтись пожалуй всегда, ну или почти всегда.
Разве кеш в доктрине не сбрасывается по модификации данных?
Если да — тогда пусть срок жизни будет хоть 100лет :-)
Если да — тогда пусть срок жизни будет хоть 100лет :-)
Может я что-то криво делал, но по моему не сбрасывает :)
«You should always consider using a result cache if the data returned by the query does not need to be up-to-date at any time.»
Я сам дня 3 писал умный контроллер кеша, чтобы реализовать такой вот сброс. Неужели оно было напрасно? :)
«You should always consider using a result cache if the data returned by the query does not need to be up-to-date at any time.»
Я сам дня 3 писал умный контроллер кеша, чтобы реализовать такой вот сброс. Неужели оно было напрасно? :)
к сожалению в 1.* точно не сбрасыватся :(
Мы случайно не путаем понятия DQL? Я говорю о Doctrine Query Language, Вы тоже? Или о Data Query Language? :)
Честно говоря мне тоже DQL совсем не нравится
По мне, так DQL — это костыль. Хотя, может и есть ситуации, когда база часто переезжает с одного движка на другой и благодаря ему код не нужно переписывать.
НЛО прилетело и опубликовало эту надпись здесь
а вы часто с одно СУБД на другую переезжаете?
Я думаю достаточно одного переезда (что автор поста выше и подчеркнул), чтобы такая абстракция полностью оправдала себя.
Еще как вариант: на девелоперских машинах стоит что-то из опенсорса, а на боевой, например Оракл.
Кроме того, если говорить об абстракции DQL, то она не только абстрагирует нас от СУБД, но и от таблиц вообще.
Еще как вариант: на девелоперских машинах стоит что-то из опенсорса, а на боевой, например Оракл.
Кроме того, если говорить об абстракции DQL, то она не только абстрагирует нас от СУБД, но и от таблиц вообще.
В том-то и дело что у меня был один такой переход с mysql на postgres.
В проекте использовался adodb для работы с базами, а все запросы обычным SQL.
И никаких проблем с переходом не было. Просто переписал пару запросов. И все.
Может мне и повезло но запросов в том проекте было много :)
в варианте:
по-моему очень велика вероятность выложить в продакшен код, который под ораклом будет работать неправильно. И программист не заметит этого, потому что тестит в другой субд.
Понимаю что оракл, сука, дорогой. Но в коммерческом проекта так рисковать не стоит :)
>
Можно пример? что это дает и где это может быть полезно?
В проекте использовался adodb для работы с базами, а все запросы обычным SQL.
И никаких проблем с переходом не было. Просто переписал пару запросов. И все.
Может мне и повезло но запросов в том проекте было много :)
в варианте:
на девелоперских машинах стоит что-то из опенсорса, а на боевой, например Оракл.по-моему очень велика вероятность выложить в продакшен код, который под ораклом будет работать неправильно. И программист не заметит этого, потому что тестит в другой субд.
Понимаю что оракл, сука, дорогой. Но в коммерческом проекта так рисковать не стоит :)
>
то она не только абстрагирует нас от СУБД, но и от таблиц вообще.Можно пример? что это дает и где это может быть полезно?
Я вот считаю что абстрагироваться от СУБД и таблиц вообще несомненно нужно, но DQL — далеко не самое красивое решение. Почему это просто не реализовать классами/методами с цепочками вызовов? Было бы намного естественней с таким работать.
В DQL был бы смысл, если бы его использовали к примеру различные библиотеки причем на различных языках программирования — вот тогда да, возможно стоило бы ввести отдельный язык… и то очень сомнительно.
То есть, речь не о том, что DQL в Doctrine не нужен вовсе, речь в том, что возможно стоило бы это реализовать так, как я писал выше. Что вы думаете по этому поводу?
В DQL был бы смысл, если бы его использовали к примеру различные библиотеки причем на различных языках программирования — вот тогда да, возможно стоило бы ввести отдельный язык… и то очень сомнительно.
То есть, речь не о том, что DQL в Doctrine не нужен вовсе, речь в том, что возможно стоило бы это реализовать так, как я писал выше. Что вы думаете по этому поводу?
НЛО прилетело и опубликовало эту надпись здесь
Давно слежу за развитием Doctrine 2.0, и она все больше похожа на Hibernate, что радует =)
Еще хотел заметить что мне кажется немного неоправданным полный переход на php5.3, docBlock ведь можно было парсить еще с выходом пятерки. В данный момент это может немного оттолкнуть начинающих разработчиков, у которых хостеры не поддерживают php5.3
Получается что они это сделали только из-за нейм-спейсов и __callStatic (ну какие есть еще в php5.3 фишки, полезные для Doctrine и используемые там, чтобы ради них отказаться от совсестимости с 5.2 веткой?)
Получается что они это сделали только из-за нейм-спейсов и __callStatic (ну какие есть еще в php5.3 фишки, полезные для Doctrine и используемые там, чтобы ради них отказаться от совсестимости с 5.2 веткой?)
static keyword, анонимные функции\замыкания — собственно это там используется, судя по коду
когда оно релизнется, 5.3 уже будет не так страшно.
По-моему, getDocComment доступен был ещё и до php 5.3
В любом случае, разработчики Doctrine — молодцы. Двигаются в правильном направлении.
Recess хорош, очень напоминает web2py.
Спасибо интересно посмотреть :)
В любом случае, разработчики Doctrine — молодцы. Двигаются в правильном направлении.
Recess хорош, очень напоминает web2py.
Спасибо интересно посмотреть :)
Да, я тоже писал что имхо — можно было и не переходить на php5.3.
Ну в принципе, да. Будем надеяться, что когда это будет стабильной версией, большинство хостеров перейдет на php5.3
По поводу web2py — действительно интересно, думал раньше что для питона джанга — вне конкуренции. Web based admin interface с генеративными возможностями это круто я считаю )
Ну в принципе, да. Будем надеяться, что когда это будет стабильной версией, большинство хостеров перейдет на php5.3
По поводу web2py — действительно интересно, думал раньше что для питона джанга — вне конкуренции. Web based admin interface с генеративными возможностями это круто я считаю )
Для питона ещё и pylons есть :)
Дружит с SQLAlchemy, значит можно прикрутить Elixir.
И ребята из pocoo тоже крутые штуки делают!
Но вообще для топика в блоге ПХП это уже много ссылок :)
Дружит с SQLAlchemy, значит можно прикрутить Elixir.
И ребята из pocoo тоже крутые штуки делают!
Но вообще для топика в блоге ПХП это уже много ссылок :)
В Yii очень даже ничего.
Спасибо!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вот он какой, Doctrine 2.0 (Приурочено к релизу Doctrine 2.0 Alpha 3)