PHP Doctrine и большие проекты
…и еще немного о работе 
Опробовав Doctrine на двух довольно больших проектах (они еще не закончены слава богу), могу сделать следующие выводы (ИМО):
- считать что этот ORM реализует бизнес-логику - глупо
- автор Doctrine разрабатывал продукт под нужды небольших проектов и команд
- описывать таблицы из кода - очень неудобно
- …так же как и связи
- поднять оценку до 3 из 5 для Doctrine можно было бы реализовав setter’ы и getter’ы защищенными
- …и связи между таблицами тоже
- LSB очень не хватает
Июнь 23rd, 2008 at 19:18
Алексей, а ты случаем Propel не пробовал? Интересно твоё мнение по этому поводу.
Июнь 23rd, 2008 at 23:03
К сожалению не довелось, так как Propel был отброшен еще на стадии анализа требований и возможностей… Основными минусами были низкая производительность и недостаточное качество кода (и синтаксис в том числе)
Дополнительно хотел бы еще сказать что хоть Propel более функциональный, но тем не менее уже Doctrine более чем достаточно. Я бы даже сказал - чересчур. Вместо расширяемость в ширь, я бы, на месте автора, расширялся вглубь (а багов-то и просто мест для рефакторинга реально хватает)
Июль 4th, 2008 at 12:28
А хвалил-то, хвалил… Есть два больших и интересных промышленных подхода для реализации ORM:
- описываешь бизнес-объектов (БО), структуру БД и связи БО с таблицами. Запускаешь генератор и он тебе строгает по каждому БО класс модели с описанием API БО. В итоге имеешь большие и толстые классы, которые наследуешь, с не всегда оптимизированной логикой, которую ты поправить не можешь. Потому что следующая правка схемы -> перегенерация восстановит базовый класс.
- описываешь бизнес-объектов (БО), структуру БД и связи БО с таблицами. движок генерирует рантайм классы, кеширует и ты работаешь с ними через интерфейс, который виртуализирует вызовы. Тупая логика компенсируется руцями-прописанным маппингом и кусками SQL (в схеме).
Первый подход есть для РНР (Propel, Doctrine), но по сравнению с тем же вылизанным hybernate для джавы - он тупо сосет, как младенец сиську.
Второго - нет
Все эти подходы ростут от ленивости писать заточенные классы сразу руками. Так что всегда в данный момент времени тебе просто надо искать баланс между сырым но типа крутым подходом и ручной работой.
Кстати думаю если спортировать hybernate или ibatis sqlmap на РНР, пых-пых будет большую часть ресурсов и времени тупо тратить на их логику. Язык все-таки легковесный, не тягаться ему с джавой по мощностям.
Август 18th, 2008 at 16:39
Помоему Doctrine очень стОящая штука. Генератор таблиц и связей из yaml очень удобен и в то же самое время конфиг не морозит глаза как какой-нибудь xml-ый. По поводу “реализации бизнес-логики” - это с каких это пор ORM должна реализовывать бизнес-логику????
Doctrine всегда был и будет более функциональным чем Propel.
Если портировать Hibernate на PHP то он явно не будет ввидел PHP кода, а только как расширение (dll).
Вообще “выставляя баллы” неплохо бы их подкреплять какими-либо доказательствами
Октябрь 27th, 2008 at 13:22
> Основными минусами были низкая производительность и недостаточное качество кода (и синтаксис в том числе) - o Propel
Есть подозрение что вы пробовали 1.2, попробуйте 1.3, на рельных задачах он быстрее в 1,5 - 2 раза чем Доктрин, в т.ч. за счет очень мощного пула объектов, гараздо меньшему расходу памяти, более простой архитектуре (в частности инстансы не тягают за собой описание модели - отсутствие циклических ссылок), действительных багов уже давно не находится - елинственное исключение - поддержка нестед-сет, она простая (правда не проще чем в доктрин ;)).
Вообще, в реальном проекте командой поработали с доктрин 3 месяца, устав бороться с багами, диким расходом памяти и не соответствием документации реальному API была (у меня) задача оценить новый пропел - r слову юзал его с беты на своих проектах, показал реальные преимущества, через 2 дня порта проблем больше не имели.
Октябрь 27th, 2008 at 13:25
дополнение (не поместилось)
Doctrine сырой и тяжелый продукт с перегруженным API, Propel готовый, отточенный и легковесный с единственным недостатком - длительное вхождение.