Автор Тема: Zend Framework vs Symfony.  (Прочитано 12601 раз)

0 Пользователей и 1 Гость смотрят эту тему.

Оффлайн vexder

  • Участник форума
  • Сообщений: 7
  • Карма: 2
Zend Framework vs Symfony.
« : Май 07, 2009, 01:15:11 »
Всем привет! После года изобретания велосипеда (написания собственного фреймворка) всё же хочу пересесть на то, что уже есть. Пока смотрю на популярные вещи: Symfony и Zend Framework. Выбор этот очень и очень сложный, так как я понимаю, что на изучение того или иного фреймворка потребуется много времени и ещё больше предстоит с ним работать в перспективе. Я итак убил кучу времени на написание того, что давно сделали за меня гораздо проще и лучше, по этому скакать с фреймворка на фреймовк очень не хочется. По этому критерии для выбора очевидные - мощный первоначальный функционал и большие перспективы.

Скажу сразу, что ни с симфонией ни с ZF не работал. Изучал плюсы и минусы исключительно методом гугления. И вот какие выводы я сделал лично для себя, полагаясь на свои требования:

Symfony. Плюсы:
  • Полноценная MVC. Зажимают в рамки, но зато сложнее наломать дров и написать неправильный код. В то же время, всегда, при желании, можно изменить и добавить практически всё что угодно.
  • ORM Doctrine и плагин DBFinder - по-моему, о лучшем и мечтать нельзя.
  • CRUD и возможность генерировать 99% бэкэнда (да и фронтэнда) обычными yml-файлами. Пожалуй, это самый главный и жирнейший плюс, без которого будет очень и очень тяжко. В силу специфики деятельности, приходится писать разные админки с кучей различной степени сложности связей, таблиц с сортировками, фильтрами, разнотипными данными, форм и т.п. И всё это отнимает очень много времени - рисование всех этих мультиселектов, чекбоксов, получение и передача данных во View. Составление запросов, заполнение и обработка форм, заполнение таблиц... Особенно весело с many-to-many связями, с комплексными формами. Аплоад файлов, древовидные структуры, меню, подменю, ACL ко всему этому... С генератором же все эти проблемы полностью решаются за счёт написания конфигов в несколько строк, а после генерации любой сгеренённый метод можно без проблем поменять, если надо где-то применить custom-решение. В общем, если вы когда-либо разрабатывали сложные админки, то поймёте, о чём я говорю.
  • Делая выводы - rock solid, rapid & agile.

Symfony. Минусы:
  • Динамика развития очень удручает. 95% всего как было написано несколько лет назад, так остаётся и по сей день. А с уходом главного идейного вдохновителя перспективы фреймворка вообще очень туманны. Щас всё подвешено на одном человеке, который тоже может взять и свалить и вместо симфонии получится какофония ...
  • Непонятные плагины. Как я понял, всё что неофициально - сырое и конфликтует друг с другом. Хотя, вкусных плагинов на первый взгляд очень много.
  • Баги и недоработки, которыми пугают многие. Которые не спешат фиксить в связи с плохой скоростью развития.
  • Можно сказать самый медленный из всех PHP-фреймворков.

Zend Framework. Плюсы:
  • От разработчиков PHP :) А это, что называется, "на года"! Выкатили на рынок всё и сразу, как снег на голову, мгновенно взяв планку самого навороченного фреймворка.
  • Есть куча нужных и удобных компонентов, работа с формами очень логичная и удобная.
  • Все компоненты можно использовать действительно как отдельные, независимые друг от друга утилиты.
  • Zend_View на первый взгляд даёт огромное количество хелперов на все случаи жизни. Но это лишь утишение в связи с отсутствием генератора, который должен сам делать всё это.
  • Вроде бы минимум багов, максимум ООП и грамотного оттещенного кода, который проходит через Core Team.
  • Множество комьюнити и, вообще, ZF стал сразу же самым популярным и динамически развивающимся из PHP-фреймворков.

Zend Framework. Минусы:
  • Нет ORM, нет генератора бэкэндов. По сути, это просто убивает всё желание заниматься им, т.к. придётся писать всё руками, рисовать шаблоны и т.п. Нашёл, как можно присобачить Doctrine, но это уже не будет solid-фреймворком, т.к. это даже не плагин и и официально он не поддерживается. А с table data gateway паттерном уже намучалтся, т.к. в своём фреймворке именно к нему пришёл самостоятельно, но потом дополнил его ActiveRecord-ом, который на порядок облегчил работу.
  • В proposals люди просили сделать и то и то и много чего полезного ещё год назад, но разработчики уделяют внимание всякой ненужной хрени типа Zend_Service_* В общем, позиция разрабов пока что не ясна до конца.
  • В тех же proposals в упор не врублюсь, как посмотреть то, над чем щас работают разработчики и то, над чем они будут работать в будущем. К примеру, codegenerator уже выпущен, а в proposals он находится в New, т.е. по сути даже ещё не рассмотренный Zend'ом. http://framework.zend.com/wiki/display/ZFPROP/Zend_CodeGenerator+-+Ralph+Schindler Как так? :)

Так получилось, что плюсы симфонии - минусы зенда и наоборот.


Что скажете? Какие у вас были минусы в выбранных вами фреймворках и как вы их преодолели, пережили какие-то потери и за счёт каких плюсов всё же отдали предпочтение тому или иному фреймворку? Буду благодарен за конструктив.
« Последнее редактирование: Май 07, 2009, 01:18:41 от vexder »

Оффлайн IgorN

  • Team
  • Герой
  • ***
  • Сообщений: 2908
  • Карма: 90
    • Мой сайт
Re: Zend Framework vs Symfony.
« Ответ #1 : Май 07, 2009, 09:48:21 »
Насчет скаффолдинга в зф, уже появились инструменты, можнот нагуглить статьи где создаются формы по модели и т.д. Можно сделать генератор моделей, контроллеров и вьюх. Благодаря коде генератору и зенд_тулс можно написать инструмент для своих нужд. Я выбрал зф так как он стабилен, красив и легко расширяем. И позволяет сделать все, что душе угодно. Пресмотритесь к последней версии, там много чего интересного.
Лично я скаффолдинг считаю ерундой. Кстати написать свой грид для построения таблиц с фильтрацией, сортировкой, постраничной навигацией и т.д. всего день делов.

Если для вас кретично именно плюсы симфони присмотритесь к Ruby on Rails в нем вам даже конфигурционные файлы писать не прийдется. И дров вы там точно не наломаете. Ну а плагинов там дофига. Симфони лишь жалкое подобие рельсов.
Мой сайт: http://igor-negrutsa.info/
Я знаю только то,что ничего не знаю, а многие не знают даже этого.

Оффлайн vexder

  • Участник форума
  • Сообщений: 7
  • Карма: 2
Re: Zend Framework vs Symfony.
« Ответ #2 : Май 07, 2009, 11:37:28 »
Угу, нагуглил много чего. Букмарков набилось прилично. На счёт RoR - сдерживает лишь специфика работы - не везде стоит RoR. Хотя, признаться, идеология руби - самое оно для меня - меньше работы, больше результата.

Вот, кстати, нагуглил очень крутую штуку http://code.google.com/p/kontorx/ У него ещё есть http://code.google.com/p/kontorx-cms/ на базе KontorX. Не встречал нигде в инете упоминаний, хотя по сути человек написал и полноценный скаффолдинг с поддержкой аякса, инлайн-эдита и т.п., и семантический поиск и кучу ещё всяких полезностей. Можно прикрутить к GWT. На такой проект точно ушёл не один день работы :) Жаль, что комменты по-польски. Но это, по сути, то, что мне сейчас и нужно. И лицензия BSD/GPL. Пока что такого не встречал, лишь бесполезные сниппеты и выдержки из чужих движков, которые полностью не афишируются. Всё же это неплохое подспорье для освоения зенда :)
« Последнее редактирование: Май 07, 2009, 11:40:06 от vexder »

Оффлайн IgorN

  • Team
  • Герой
  • ***
  • Сообщений: 2908
  • Карма: 90
    • Мой сайт
Re: Zend Framework vs Symfony.
« Ответ #3 : Май 07, 2009, 12:10:55 »
Ага, с чего то надо начинать :) Глядишь, напишите свой инструмент который идеально вам подойдет.
Мой сайт: http://igor-negrutsa.info/
Я знаю только то,что ничего не знаю, а многие не знают даже этого.

Оффлайн IgorN

  • Team
  • Герой
  • ***
  • Сообщений: 2908
  • Карма: 90
    • Мой сайт
Re: Zend Framework vs Symfony.
« Ответ #4 : Май 07, 2009, 12:13:13 »
Интересно будет глянуть на kontorx, кто будет смотреть отпишитесь о впечатлениях.
Мой сайт: http://igor-negrutsa.info/
Я знаю только то,что ничего не знаю, а многие не знают даже этого.

Оффлайн atukai

  • Team
  • Опытный
  • ***
  • Сообщений: 223
  • Карма: 17
Re: Zend Framework vs Symfony.
« Ответ #5 : Май 07, 2009, 12:24:16 »
Кстати написать свой грид для построения таблиц с фильтрацией, сортировкой, постраничной навигацией и т.д. всего день делов.

Ой что-то мне кажется Вы ошибаетесь...

Оффлайн Zh0rzh

  • Team
  • Герой
  • ***
  • Сообщений: 1312
  • Карма: 80
Re: Zend Framework vs Symfony.
« Ответ #6 : Май 07, 2009, 12:37:31 »
Действительно почему у Zend_CodeGenerator статус "Initial Draft"

Оффлайн san

  • Администратор
  • Герой
  • *****
  • Сообщений: 2158
  • Карма: 95
  • zf infected
    • Развитие личности от Александра Махомета
Re: Zend Framework vs Symfony.
« Ответ #7 : Май 07, 2009, 15:09:49 »
Цитировать
Нет ORM, нет генератора бэкэндов. По сути, это просто убивает всё желание заниматься им, т.к. придётся писать всё руками, рисовать шаблоны и т.п. Нашёл, как можно присобачить Doctrine, но это уже не будет solid-фреймворком, т.к. это даже не плагин и и официально он не поддерживается. А с table data gateway паттерном уже намучалтся, т.к. в своём фреймворке именно к нему пришёл самостоятельно, но потом дополнил его ActiveRecord-ом, который на порядок облегчил работу.

Вот что пишет Matthew Weier O'Phinney по поводу выбора TDG

Цитировать
The Model is a complex subject. However, it is often boiled down to either a single model class or a full object relational mapping (ORM). I personally have never been much of a fan of ORMs as they tie models to the underlying database structure; I don't always use a database, nor do I want to rely on an ORM solution too heavily on the off-chance that I later need to refactor to use services or another type of persistence store. On the other hand, the model as a single class is typically too simplistic.

I am, however, a fan of the Domain Model. To quote wikipedia,

    [The] domain model can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relationships.

When you think in these terms, you start breaking your system into discrete pieces that you need to manipulate, as well as consider how each piece relates to the others. This type of exercise also helps you stop thinking of your model in terms of database tables; instead, your database becomes the container in which data is persisted from one use of your model to the next. Your model instead is an object that can do things with either incoming or stored data -- or even completely autonomously.

As an example, when starting with Zend Framework, it's tempting to use Zend_Db_Table and Zend_Db_Table_Row as models. However, there's one big argument against doing so: when using a Table Data Gateway (TDG) or a Row Data Gateway (RDG), you're returning an object that is tied to the data storage implementation. You're basically putting on blinders and thinking of your model as simply the database table or an individual row, and the returned objects reflect this narrow view point. Furthermore, if you want to re-use your models with service layers, many web services do not work with objects, and of those that do, you likely do not want to expose all the properties and methods of the objects returned by your data provider. A row object in ZF, for instance, actually stores the data in protected members, effectively hiding it from services, and also includes methods for deleting the row, ArrayAccess methods, and access to the table object -- which gives you full control over the table! The security implications of exposing this directly over a service should be obvious.

Цитировать
There are several differences. First, classic ActiveRecord doesn't use instances to access individual items, but instead uses static access (this varies from implementation to implementation). Second, ActiveRecord typically doesn't rely on a separate data access layer that needs to be injected, but instead contains this access internally (it may come from a separate component, but instantiation and handling of that component is entirely internal).

The domain model typically involves a certain amount of dependency injection - i.e., the class may need certain artifacts, such as the database connection, ACLs, etc. This makes use a bit more complicated -- you need to provide arguments at instantiation -- but also makes it more flexible.

Finally, the way the examples here are defined, they could actually *consume* ActiveRecords to handle data persistence; it's actually common in domain models to use TDG or AR for that purpose.
http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

Касательно автоматической генерации afaik у разработчиков большие планы на Zend_Tool и с выходом ZF 2.0 мы возможно получим что-то весьма интересное.

Я бы делал ставку на ZF так как вы верно отметили что ZF действительно стремительно развивается и уже можно сказать стал лидером среди фреймворков.

и с Doctrine  тоже возможно скоро появится более полноценная дружба http://framework.zend.com/wiki/pages/viewpage.action?pageId=3866950&focusedCommentId=10944686#comment-10944686

хотя с symfony я толком не работал.
« Последнее редактирование: Май 07, 2009, 16:31:19 от san »

Оффлайн IgorN

  • Team
  • Герой
  • ***
  • Сообщений: 2908
  • Карма: 90
    • Мой сайт
Re: Zend Framework vs Symfony.
« Ответ #8 : Май 07, 2009, 15:46:33 »
Кстати написать свой грид для построения таблиц с фильтрацией, сортировкой, постраничной навигацией и т.д. всего день делов.

Ой что-то мне кажется Вы ошибаетесь...

Да ну... вот как раз недавно, мой коллега, кстати новичек в зенде написал грид. Сейчас активно используем в админке. У него конечно немного больше 8 часов ушло но он новичек. Позже доп. время ушло, что бы сделать аяксовые действия (примерно еще 4 часа).
Кстати полностью аяксовый грид с использованием ExtJs можно сделать еще в 2-3 раза быстрее. Там только данные в нужный формат конвертить.
Мой сайт: http://igor-negrutsa.info/
Я знаю только то,что ничего не знаю, а многие не знают даже этого.

Оффлайн atukai

  • Team
  • Опытный
  • ***
  • Сообщений: 223
  • Карма: 17
Re: Zend Framework vs Symfony.
« Ответ #9 : Май 07, 2009, 16:53:17 »
Да ну... вот как раз недавно, мой коллега, кстати новичек в зенде написал грид. Сейчас активно используем в админке. У него конечно немного больше 8 часов ушло но он новичек. Позже доп. время ушло, что бы сделать аяксовые действия (примерно еще 4 часа).
Кстати полностью аяксовый грид с использованием ExtJs можно сделать еще в 2-3 раза быстрее. Там только данные в нужный формат конвертить.

Если под гридом вы имеете в виду вывод списка, то да, пожалуй я с вами соглашусь. Но под полноценным гридом я понимаю и генерацию форм добавления и редактирования, управление фильтрами, декораторы колонок, сортировки. Думаю за день такое не сделаешь. Причем что бы все было выдержано в лучших традициях ZF.

Оффлайн IgorN

  • Team
  • Герой
  • ***
  • Сообщений: 2908
  • Карма: 90
    • Мой сайт
Re: Zend Framework vs Symfony.
« Ответ #10 : Май 07, 2009, 17:28:08 »
То, что вы описали не есть грид, а есть скаффолдинг, когда сразу доступны такие действие как создать, удалить и редактировать и готовы экшены к нему, формы и модели.

P.S. Люди, а кто и за, что постоянно карму уменьшает?
Мой сайт: http://igor-negrutsa.info/
Я знаю только то,что ничего не знаю, а многие не знают даже этого.

Оффлайн Zh0rzh

  • Team
  • Герой
  • ***
  • Сообщений: 1312
  • Карма: 80
Re: Zend Framework vs Symfony.
« Ответ #11 : Май 07, 2009, 17:38:35 »
P.S. Люди, а кто и за, что постоянно карму уменьшает?

Тролли!!! :)

Получи плюс!

Оффлайн vexder

  • Участник форума
  • Сообщений: 7
  • Карма: 2
Re: Zend Framework vs Symfony.
« Ответ #12 : Май 08, 2009, 03:20:40 »
Цитировать
Нет ORM, нет генератора бэкэндов. По сути, это просто убивает всё желание заниматься им, т.к. придётся писать всё руками, рисовать шаблоны и т.п. Нашёл, как можно присобачить Doctrine, но это уже не будет solid-фреймворком, т.к. это даже не плагин и и официально он не поддерживается. А с table data gateway паттерном уже намучалтся, т.к. в своём фреймворке именно к нему пришёл самостоятельно, но потом дополнил его ActiveRecord-ом, который на порядок облегчил работу.

Вот что пишет Matthew Weier O'Phinney по поводу выбора TDG

Цитировать
The Model is a complex subject. However, it is often boiled down to either a single model class or a full object relational mapping (ORM). I personally have never been much of a fan of ORMs as they tie models to the underlying database structure; I don't always use a database, nor do I want to rely on an ORM solution too heavily on the off-chance that I later need to refactor to use services or another type of persistence store. On the other hand, the model as a single class is typically too simplistic.

I am, however, a fan of the Domain Model. To quote wikipedia,

    [The] domain model can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relationships.

When you think in these terms, you start breaking your system into discrete pieces that you need to manipulate, as well as consider how each piece relates to the others. This type of exercise also helps you stop thinking of your model in terms of database tables; instead, your database becomes the container in which data is persisted from one use of your model to the next. Your model instead is an object that can do things with either incoming or stored data -- or even completely autonomously.

As an example, when starting with Zend Framework, it's tempting to use Zend_Db_Table and Zend_Db_Table_Row as models. However, there's one big argument against doing so: when using a Table Data Gateway (TDG) or a Row Data Gateway (RDG), you're returning an object that is tied to the data storage implementation. You're basically putting on blinders and thinking of your model as simply the database table or an individual row, and the returned objects reflect this narrow view point. Furthermore, if you want to re-use your models with service layers, many web services do not work with objects, and of those that do, you likely do not want to expose all the properties and methods of the objects returned by your data provider. A row object in ZF, for instance, actually stores the data in protected members, effectively hiding it from services, and also includes methods for deleting the row, ArrayAccess methods, and access to the table object -- which gives you full control over the table! The security implications of exposing this directly over a service should be obvious.

Цитировать
There are several differences. First, classic ActiveRecord doesn't use instances to access individual items, but instead uses static access (this varies from implementation to implementation). Second, ActiveRecord typically doesn't rely on a separate data access layer that needs to be injected, but instead contains this access internally (it may come from a separate component, but instantiation and handling of that component is entirely internal).

The domain model typically involves a certain amount of dependency injection - i.e., the class may need certain artifacts, such as the database connection, ACLs, etc. This makes use a bit more complicated -- you need to provide arguments at instantiation -- but also makes it more flexible.

Finally, the way the examples here are defined, they could actually *consume* ActiveRecords to handle data persistence; it's actually common in domain models to use TDG or AR for that purpose.
http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

Касательно автоматической генерации afaik у разработчиков большие планы на Zend_Tool и с выходом ZF 2.0 мы возможно получим что-то весьма интересное.

Я бы делал ставку на ZF так как вы верно отметили что ZF действительно стремительно развивается и уже можно сказать стал лидером среди фреймворков.

и с Doctrine  тоже возможно скоро появится более полноценная дружба http://framework.zend.com/wiki/pages/viewpage.action?pageId=3866950&focusedCommentId=10944686#comment-10944686

хотя с symfony я толком не работал.

Интересно. Судя по статье http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html Мэтью вообще не приемлит ORM, хотя в примере он попытался изобрести тот же Active Record за счёт __set и __get. В общем, простейшая схема вполне жизнеспособна, пока не сталкнёшься со сложной структурой, когда хочется оперировать с объектом и не задумываться о его дочерних/корневых связях. А это простейший пример $author->article, когда хочется работать с article, вообще не задумываясь о её связи с author. Он там написал, что его лично это не парят подобные вопросы и что он лично пишет другие вещи, по этому, видимо, ему хватает table gateway и, следовательно, такая политика партии. Надеюсь, это поправится в будущем.

Оффлайн Keel

  • Опытный
  • ***
  • Сообщений: 212
  • Карма: 45
Re: Zend Framework vs Symfony.
« Ответ #13 : Май 08, 2009, 10:40:24 »
По-моему, подход, который предлагает Мэтью даже более гибок, чем ORM.

Мэтью отделяет зависимости от модели через шлюз к домену. Таким образом, модель вообще не заботит структура базы и какие бы то ни было зависимости. Когда ей что-то нужно - она может лениво подгружать зависимости через шлюз. А шлюз может их доставать самым разным образом, включая выборку из кэша, из сессии, из базы с любой структурой или даже веб-сервисов.

Минус этого подхода там же где и плюс - шлюз придется все равно программировать, вместо (относительно) простого описания структуры связей в ORM.

Еще один важный момент, ORM - это готовый механизм/технология, а Мэтью предлагает архитектурное решение, которое вас не привязывает к конкретной его реализации. Поэтому я и вижу его решение как более гибкое.

Оффлайн kindrosker

  • Новичок
  • *
  • Сообщений: 1
  • Карма: 0
    • qdPM - open source project management software
Re: Zend Framework vs Symfony.
« Ответ #14 : Декабрь 15, 2009, 16:25:08 »
я уже как год занимаюсь симфони и пишу сейчас свой open source проект http://qdpm.net/
Так же сталкивался с зендом

Мое мнение такое, оба фреймворка очень мощны и выбор между ними это скорей всего дело личное и перед тем как делать такой выбор нужно понимать что для эффективной работы с Zend Framework по началу нужно приспособится,  сифони же предлагает свои инструменты для автоматизации рабочего процесса

я сделал выбор в пользу симфони потому что кроме CRUD и генерации backend там еще генерится полностью вся модель в которой по умолчанию создаются все необходимы методы, выборки из таблиц и связанных таблиц.

и в результате получается отличный каркас в который нужно только дополнить а не изобретать велосипед заново.

но давайте посмотрим в будущее, в следующей конференции будет обсуждаться "using Symfony and Zend Framework together"
http://www.symfony-project.org/blog/2009/12/15/symfony-live-conference-2010-updates

тут уже можно ознакомится как юзать зенд  и симфони http://fabien.potencier.org/media/talk/2009/symfony-and-zend-framework-together-2009.pdf

так что можно использовать все это по отдельности или в месте, опять же кому как удобнее и эффективнее в рабочем процессе.
« Последнее редактирование: Май 03, 2010, 20:23:39 от kindrosker »