Комментарии на: PHP Doctrine и большие проекты http://blog.azazel.org.ua/2008/06/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/ Just another WordPress weblog Wed, 10 Mar 2010 20:18:23 +0000 http://wordpress.org/?v=2.5.1 От: standov http://blog.azazel.org.ua/2008/06/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-947 standov Mon, 27 Oct 2008 10:25:11 +0000 http://blog.azazel.org.ua/2008/06/23/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-947 дополнение (не поместилось) Doctrine сырой и тяжелый продукт с перегруженным API, Propel готовый, отточенный и легковесный с единственным недостатком - длительное вхождение. дополнение (не поместилось)
Doctrine сырой и тяжелый продукт с перегруженным API, Propel готовый, отточенный и легковесный с единственным недостатком - длительное вхождение.

]]> От: standov http://blog.azazel.org.ua/2008/06/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-946 standov Mon, 27 Oct 2008 10:22:14 +0000 http://blog.azazel.org.ua/2008/06/23/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-946 > Основными минусами были низкая производительность и недостаточное качество кода (и синтаксис в том числе) - o Propel Есть подозрение что вы пробовали 1.2, попробуйте 1.3, на рельных задачах он быстрее в 1,5 - 2 раза чем Доктрин, в т.ч. за счет очень мощного пула объектов, гараздо меньшему расходу памяти, более простой архитектуре (в частности инстансы не тягают за собой описание модели - отсутствие циклических ссылок), действительных багов уже давно не находится - елинственное исключение - поддержка нестед-сет, она простая (правда не проще чем в доктрин ;)). Вообще, в реальном проекте командой поработали с доктрин 3 месяца, устав бороться с багами, диким расходом памяти и не соответствием документации реальному API была (у меня) задача оценить новый пропел - r слову юзал его с беты на своих проектах, показал реальные преимущества, через 2 дня порта проблем больше не имели. > Основными минусами были низкая производительность и недостаточное качество кода (и синтаксис в том числе) - o Propel

Есть подозрение что вы пробовали 1.2, попробуйте 1.3, на рельных задачах он быстрее в 1,5 - 2 раза чем Доктрин, в т.ч. за счет очень мощного пула объектов, гараздо меньшему расходу памяти, более простой архитектуре (в частности инстансы не тягают за собой описание модели - отсутствие циклических ссылок), действительных багов уже давно не находится - елинственное исключение - поддержка нестед-сет, она простая (правда не проще чем в доктрин ;)).

Вообще, в реальном проекте командой поработали с доктрин 3 месяца, устав бороться с багами, диким расходом памяти и не соответствием документации реальному API была (у меня) задача оценить новый пропел - r слову юзал его с беты на своих проектах, показал реальные преимущества, через 2 дня порта проблем больше не имели.

]]> От: ggeeek http://blog.azazel.org.ua/2008/06/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-856 ggeeek Mon, 18 Aug 2008 14:39:06 +0000 http://blog.azazel.org.ua/2008/06/23/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-856 Помоему Doctrine очень стОящая штука. Генератор таблиц и связей из yaml очень удобен и в то же самое время конфиг не морозит глаза как какой-нибудь xml-ый. По поводу "реализации бизнес-логики" - это с каких это пор ORM должна реализовывать бизнес-логику???? :) Doctrine всегда был и будет более функциональным чем Propel. Если портировать Hibernate на PHP то он явно не будет ввидел PHP кода, а только как расширение (dll). Вообще "выставляя баллы" неплохо бы их подкреплять какими-либо доказательствами :) Помоему Doctrine очень стОящая штука. Генератор таблиц и связей из yaml очень удобен и в то же самое время конфиг не морозит глаза как какой-нибудь xml-ый. По поводу “реализации бизнес-логики” - это с каких это пор ORM должна реализовывать бизнес-логику???? :)
Doctrine всегда был и будет более функциональным чем Propel.

Если портировать Hibernate на PHP то он явно не будет ввидел PHP кода, а только как расширение (dll).

Вообще “выставляя баллы” неплохо бы их подкреплять какими-либо доказательствами :)

]]> От: chiffa http://blog.azazel.org.ua/2008/06/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-804 chiffa Fri, 04 Jul 2008 09:28:23 +0000 http://blog.azazel.org.ua/2008/06/23/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-804 А хвалил-то, хвалил... Есть два больших и интересных промышленных подхода для реализации ORM: - описываешь бизнес-объектов (БО), структуру БД и связи БО с таблицами. Запускаешь генератор и он тебе строгает по каждому БО класс модели с описанием API БО. В итоге имеешь большие и толстые классы, которые наследуешь, с не всегда оптимизированной логикой, которую ты поправить не можешь. Потому что следующая правка схемы -> перегенерация восстановит базовый класс. - описываешь бизнес-объектов (БО), структуру БД и связи БО с таблицами. движок генерирует рантайм классы, кеширует и ты работаешь с ними через интерфейс, который виртуализирует вызовы. Тупая логика компенсируется руцями-прописанным маппингом и кусками SQL (в схеме). Первый подход есть для РНР (Propel, Doctrine), но по сравнению с тем же вылизанным hybernate для джавы - он тупо сосет, как младенец сиську. Второго - нет :) Все эти подходы ростут от ленивости писать заточенные классы сразу руками. Так что всегда в данный момент времени тебе просто надо искать баланс между сырым но типа крутым подходом и ручной работой. Кстати думаю если спортировать hybernate или ibatis sqlmap на РНР, пых-пых будет большую часть ресурсов и времени тупо тратить на их логику. Язык все-таки легковесный, не тягаться ему с джавой по мощностям. А хвалил-то, хвалил… Есть два больших и интересных промышленных подхода для реализации ORM:
- описываешь бизнес-объектов (БО), структуру БД и связи БО с таблицами. Запускаешь генератор и он тебе строгает по каждому БО класс модели с описанием API БО. В итоге имеешь большие и толстые классы, которые наследуешь, с не всегда оптимизированной логикой, которую ты поправить не можешь. Потому что следующая правка схемы -> перегенерация восстановит базовый класс.

- описываешь бизнес-объектов (БО), структуру БД и связи БО с таблицами. движок генерирует рантайм классы, кеширует и ты работаешь с ними через интерфейс, который виртуализирует вызовы. Тупая логика компенсируется руцями-прописанным маппингом и кусками SQL (в схеме).

Первый подход есть для РНР (Propel, Doctrine), но по сравнению с тем же вылизанным hybernate для джавы - он тупо сосет, как младенец сиську.

Второго - нет :)

Все эти подходы ростут от ленивости писать заточенные классы сразу руками. Так что всегда в данный момент времени тебе просто надо искать баланс между сырым но типа крутым подходом и ручной работой.

Кстати думаю если спортировать hybernate или ibatis sqlmap на РНР, пых-пых будет большую часть ресурсов и времени тупо тратить на их логику. Язык все-таки легковесный, не тягаться ему с джавой по мощностям.

]]> От: Алексей Токарь http://blog.azazel.org.ua/2008/06/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-771 Алексей Токарь Mon, 23 Jun 2008 21:03:38 +0000 http://blog.azazel.org.ua/2008/06/23/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-771 К сожалению не довелось, так как Propel был отброшен еще на стадии анализа требований и возможностей... Основными минусами были низкая производительность и недостаточное качество кода (и синтаксис в том числе) Дополнительно хотел бы еще сказать что хоть Propel более функциональный, но тем не менее уже Doctrine более чем достаточно. Я бы даже сказал - чересчур. Вместо расширяемость в ширь, я бы, на месте автора, расширялся вглубь (а багов-то и просто мест для рефакторинга реально хватает) К сожалению не довелось, так как Propel был отброшен еще на стадии анализа требований и возможностей… Основными минусами были низкая производительность и недостаточное качество кода (и синтаксис в том числе)

Дополнительно хотел бы еще сказать что хоть Propel более функциональный, но тем не менее уже Doctrine более чем достаточно. Я бы даже сказал - чересчур. Вместо расширяемость в ширь, я бы, на месте автора, расширялся вглубь (а багов-то и просто мест для рефакторинга реально хватает)

]]> От: Сергей http://blog.azazel.org.ua/2008/06/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-770 Сергей Mon, 23 Jun 2008 17:18:25 +0000 http://blog.azazel.org.ua/2008/06/23/php-doctrine-%d0%b8-%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b/#comment-770 Алексей, а ты случаем Propel не пробовал? Интересно твоё мнение по этому поводу. Алексей, а ты случаем Propel не пробовал? Интересно твоё мнение по этому поводу.

]]>