Собственно сабж. Кто использует? Кто пользовался, но по каким-либо причинам отказался. Почему? Кто рассматривал этот вариант но отказался в пользу другой ORM. Все остальные могут ознакомится: phpdoctrine.org
Отказался от ORM в пользу PHP. PHP слишком медленный для реализации ORM в реальных, даже средненагруженных приложениях. Для этого нужен хотя бы питон.
Участвовал в трех "реальных средненагруженных" проектах где использовалась одна самописная ORM, и ORM in onPHP... Memcached с легкостью окупает использование ORM. ИМХО А скорость и качество разработки "реальных" проектов увеличиваются за счет использования этой самой пресловутой ORM. Это опять таки ИМХО. Спорить ORM == true || ORM == false не вижу смысла. Я для себя выбор сделал в этом вопросе. Осталось выбрать реализацию. Написать что-то свое имеет конечно смысл, но только в том случае, если тебя что-то не устраивает в уже существующих реализациях. Ознакомился с Doctrine documentation и понял что если на практике так же хорошо как там описано, то это именно то что мне нужно. Отсюда возникает вопрос: кто что считает по поводу реализации PHPDoctrine как ORM.
topas Советую покопать в направлении LIMB ActiveRecord. Изо всех реализаций имхо лучшая. ORM в onPHP видел (точнее, видел сам код и примеры использования)... имхо это страшный ужас а не ORM... UPD: Собственно вот они эти примеры - http://onphp.org/examples.Forum.en.html Кто разберется, тому пирожок с полки.
нет... с ним работать конечно можно. Но сам факт того что ORM ищу в другом направлении, наверное о чем-то говорит.
По поводу ORM и Memcached. Смотрите, что-бы не получилось ситуации, когда в memcache будет столько данных, что нагрузка пойдёт на сеть (если у вас memcached на отдельной машине, а это скорее всего так, ибо такого уровня проэкты одним WEB сервером не обходятся). В практике была ситуация, когда memcache занимал ~800 Mbit, пришлось срочно оптимизировать и убирать совсем лишнее. Благо у нас это было именно хранение всяких статусов и счётчиков - много что можно было переделать по другому и трафик уменьшили сильно. В случае же с ORM так уже не сделаешь, так что палка о двух концах.
Dagdamor, активные записи - это очень-очень частный случай орм. topas, предпочитаю не привязываться к орм-у, а делать ту объектную модель, какая требуется, а объекты уже напрямую к базе обращаются, через что-то навроде препарированного активрекорда.
Не знаю как с этим в Doctrine, но в onPhp предусмотрен разный уровень кэширования для разных объектов.
Psih, мемкэш, на то и мемкэш, что стоять должен на том же сервере, на котором происходит обработка запроса, чтобы не стучаться к бд через всю сеть.
sword dancer Вобще-то memcache сетевой демон, а вот APC или XCache - именно локальные. К тому-же, если у тебя 10 WEB серверов, на каждом будет свой кеш для ORM!?
на каждом будет стоять мемкэш для кэширования. через сеть можно и к базе стукнуться. то, что он использует сокеты в качестве интерфейса к другим программам, вовсе не означает, что его нужно сажать на отдельную машину.
sword dancer Ничего подобного. Active Record - это наоборот такое развитие ORM, при котором в частности есть поддержка связей между таблицами. ORM = привязка объекта к записи из таблицы, и ничего более.
небольшой ликбез для знатоков: orm - это отображение объектной модели предметной области на реляционную. качество отображения ( нормальность, эффективность ) напрямую зависит от качества orm ( полнота набора паттернов отображения, оптимизация запросов, кэширование ) active record - представление реляционной информации в виде объектов. полученные объекты, при этом, не имеют ничего общего с объектами предметной области ( кроме простейших частных случаев ).
sword dancer Гм... виноват. Но в сторону LIMB AR все же советую покопать, ибо все качества ORM там присутствуют.
Не ту ссылку дали. Более менее актуальный пример тут: http://gabaidulin.livejournal.com/64485.html Могу еще кусок реального кода привести: Код (Text): Criteria::create(Banner::dao())-> setDistinct()-> add( Expression::eq( 'state', BannerState::ACTIVATED ) )-> add( Expression::andBlock( Expression::eq( 'campaign.type', CampaignType::COMMERCE ), Expression::eq( 'campaign.state', CampaignState::ACTIVATED ) ) )-> add( Expression::orBlock( Expression::gt( 'campaign.limit', 0 ), Expression::isNull( 'campaign.limit' ) ) )-> add( Expression::in( 'category.id', $bannerCategoriesIds ) )->add( Expression::orBlock( Expression::andBlock( Expression::notNull( 'profile.id' ), Expression::in( 'profile.positions.position.id', $positionsIds ) ), Expression::isNull( 'profile.positions.position.id', $positionsIds ) ) )-> getList(); Выборка баннеров, которые подходят под сложное условие. Легко заметить, что "пути" - это фактически пропертя объекта.
Dagdamor Не собираюсь участвовать в споре ORM OR NOT ORM Для себя я уже давно все решил, и выигрыш от ORM на практике встречал. Вопрос только в конкретной реализации
в случае с доктриной это дело обстоит очень даже хорошо Опять-таки, доктрину использовать очень просто. Сама библиотека большая конечно, это не скрипт на несколько сотен строк, но, товарищи, не забывайте, мы работаем на PHP, исходник которого не претендует на звание самого простого кода, но смею всех уверить: инструмент наш очень даже удобен в использовании.
Программеры сами пытаются "упрощать" себе жизнь до тех пор пока не получится какой-нибудь очередной компот из фреймворков как в J2EE, где есть куча ORM на любой вкус и цвет, поверх которых лежит Spring framework, "стандартизирующий" эти решения. Здесь есть любители ОООP (over-engeneered OOP) ?