Вечный вопрос: какой фреймворк вы посоветуете для конкретных задач?

Одна из лучших архитектур

Попробуйте расширить UploadedFile что бы можно было работать с загруженными файлами так как вам надо.
Попробуйте использовать FormBuilder так что бы он подтягивал поля модели, которые являются полями другой модели у которых связь 1 к 1.
Что делать если в DI Container лежит не тот объект на который вы расчитывали, где искать ошибку?
Что делать если нужно вести историю изменения объекта, но нельзя использовать EntityManager в lifecycleCallbacks. Зачем тогда они нужны?
Почему что бы реализовать SOAP нужно встать раком? (вот где не раком: www.yiiframework.com/doc/guide/1.1/en/topics.webservice)
Почему один конфиг на все приложение(app/config/config.yml)?

Модульнее некуда

Почему мы не можем унаследоваться от Entity из FooBundle, который не знает о нашем BarBundle?

Поддержка пользователей через FOSUBundle

Какого хрена SecurityBundle как из коробки, так и из FOS такие убогие по функциональности но такие здоровые? Что за увеличение сложности. Им до RBAC в Yii далеко.

Официально русской поддержки нет, но русских много в этом коммюнити,

Почему на официальном IRC канале(англоязычном) могут помочь лишь с простейшими вопросами, а если ты хочешь узнать принцип работы какого нибудь AuthorizationBundle тебе приходится лесть в исходники и рыть самому, т.к. ни документации ни в IRC тебе помочь не могут(поисковики тоже молчат)

Полная интеграция с Doctrine

Отлично. Почему в столь прекрасной ORM невозможно сохранить не все измененные, а лишь одну измененную сущность?

Я могу продолжать очень долго.

Промахнулся с ответом, habrahabr.ru/qa/23597/#answer_96701

И, кстати, на Вашем месте я бы уделил больше внимания выбору СУБД.
Скажем так, выбрав, к примеру, Postgresql вместо MySQL, Вы оставите себе довольно много места для маневров :)

Извиняюсь, это комментарий к habrahabr.ru/qa/23597/#answer_96668 Поторопился.

А в чем проблема? В одном из проектов так и делаем.

И не меняете private свойств объекта? оО Что ж вы там расширели?

А в чем проблема? Реализуемо с EmbeddedForms + DataTransformers. Более того, опять же, в одном из проектов делаем еще более сложные махинации.

Извиняюсь, поторопился. Поля модели являются моделями. Т.е. горизонтальное расширение полей модели.

Event Listeners.

Этого делать нельзя:
docs.doctrine-project.org/projects/doctrine-orm/en/2.1/reference/events.html#postupdate-postremove-postpersist

Без конкретики не могу ответить. Мы испольузем BeSimpleSoapBundle без проблем.

Я привел в пример документацию Yii где показано, как обычный action превращается в часть API введением парочки строчек в анотацию. Никаких бандлов. Никаких ограничений на переписывание роутинга и выделение специального класса.

parameters.yml, routing.yml, security.yml, и возможность определять по бандлам services.yml и routing.yml не в счет?

Stable сейчас 2.0.17, так что говорим про это чудо. Эти конфиги не в счет. нужена область видимости именно config.yml, например что бы добавить ресурсы или стили другого бандла, лиьш поделючением его в AppKernel без тыканье в config.yml — пример корявой архитектуры

Можем.

Как? docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html

Можно.

Очередное «Как?»

И не меняете private свойств объекта? оО Что ж вы там расширели?

Ок, попался, мы переопределяли свойства. +

Извиняюсь, поторопился. Поля модели являются моделями. Т.е. горизонтальное расширение полей модели.

Ответ все равно тот же, EmbeddedForms + DataTransformers. Мб даже только EmbeddedForms можно обойтись.

Этого делать нельзя:
docs.doctrine-project.org/projects/doctrine-orm/en/2.1/reference/events.html#postupdate-postremove-postpersist

Не понял, чего делать нельзя? pre* ивенты имеют доступ к новой и старой версии модели. Посмотрите Loggable и Versionable у DoctrineExtensions.

Я привел в пример документацию Yii где показано, как обычный action превращается в часть API введением парочки строчек в анотацию. Никаких бандлов.

Ну а мы с бандлом это спокойно сделали, в чем проблема? Если ваш основной пункт — это «никаких бандлов», то я вам подскажу более очевидное место, к которому придраться — админка. Правда это ни разу не аргумент.

Stable сейчас 2.0.17, так что говорим про это чудо. Эти конфиги не в счет. нужена область видимости именно config.yml, например что бы добавить ресурсы или стили другого бандла, лиьш поделючением его в AppKernel без тыканье в config.yml — пример корявой архитектуры

Что из мной перечисленного не работает в 2.0.17? Необходимость добавлять бандл в config.yml есть только в случае если он требует какой-то… конфигурации.

Как? docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html

Просто унаследовать класс модели. См. FOSUB.

Очередное «Как?»

$em->flush($entity);

Хотя тут признаю, что немного лукавлю. Это в 2.1 версии, в 2.0 действительно не было адекватного способа. Но по секрету скажу что 2.1 сегодня-завтра выйдет в stable.

Хватит уже, а? :)

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

Просто унаследовать класс модели. См. FOSUB.

Посмотрите предложенную мною ссылку и поймете что я говорю про наслдеование от Entity, соответственно ваш примре не к месту. И сразу отвечу сам. Сделать наследования между Bundle, так что бы «родительский» Bundle не знал о «дочернем» — нельзя

Ок, попался, мы переопределяли свойства. +
Т.е. в простейших вещах нет продуманности архитектуру — пункт засчитан?

Мб даже только EmbeddedForms можно обойтись.

Покажите как, я вам не верю, на мой взгляд это невозможно. Есть ещё вероятность, что вы меня не поняли.

Про Events — я говорю о том, что там нельзя делать flush. Один из разработчиков сказал, что такое поведение ими не предполагалось и они не собираются фиксить баг, где в preUpdate добавляют сущности для сохранения.

Ну и на последок, прежде чем говорить о продуманной архитектуре, посмотрите в код:
github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L2314

Vampiro — постараюсь закруглиться и не взрываться негодованием :)

Кстати, к Yii можно прикрутить Twig — очень просто(есть даже расширение для Yii)
Очень достойный шаблонизатор

Twig хороший шаблонизатор, только когда я смотрел у него был большой недостаток, не было встроено сразу кэширование layout'ов, так и partial… Конечно можно всем этим и самому заниматься со стороны контроллера, но как-то некрасиво.

Про архитектуру аргументации нет так что опустим.

Документация — периодически слышу утверждение, что она неполная, но когда доходит до конкретных примеров выясняется что человек просто поленился поиском попользоваться.

LTE намечен на 2.3, так что в каком-то смысле вы правы. Но полностью перевести даже большой проект, с 50+ зависимостями, с 2.0 на 2.1 занимает 2-3 часа, так что не вижу проблемы. На данный момент 2.1 находится в RC состоянии — вполне стабильна. Практически все бандлы поддерживают обе версии.

P.S. Большинство минусов, описанных в вашей ссылке, связаны либо с невнимательно прочитанной документацией, либо с непониманием архитектуры (ваш порыв EntityManager пихать в Entity отличный тому пример).

Посмотрел я на «решение» вашей проблемы, как сказано выше, вы просто не потрудились изучить фреймворк, часть проблем просто из-за невнимательности или нежелания читать доки. Если вы хотели более легкий фреймворк изучить то, сразу и надо было начинать с Yii, ведь везде же написано что symfony2 очень мощный, но достаточно сложный в изучении, и в нем применяются некоторые непривычные методики (аннотации, DI и сервисы), и из-за этого многие не хотят перестриваться и думать по-новому, просто пишут код так как писали раньше не учитывая правил и концепциий фреймворка — в итоге получается то что получилось у вас.

Автору вопроса:
И Yii тоже хорошая система. Автор пусть выбирает любую, не прогадает.

Уважаемые хаброюзеры Inori и chetzof.
Даю вам наводку:
ООП создан для того что бы снизить сложность проекта.
Framework'и созданы для того что бы снизить сложность проекта в прикладной задачи соответствующей определенным критериям.
Если framework не понижает уровень сложности задачи. Если он сложен для изучения и понимания — это говорит о его плохой архитектуре строго из определения:
Архитектура framework'a плохая тогда, когда она не позволяет снизить сложность проекта, т.к. это цель его назначения.

Покажите мне хоть один мало-майски большой проект реализованный на Symfony 2.
Воду лить не надо, что ошибки из-за невнимательности. Есть момент где увидели, где я не прав, пишите конкретику. Воду, что что якобы, вы не понимаете архитектуру, можете лить блондинкам на свиданиях а не в техническом сообществе.

MpaK999
Согласен. Могу так же добавить, что не хватает реализации parent() в шаблонах которые использованы в use.
Понятно что это горизонтальное расширение, но то что родительский шаблон должен знать как именно его расширяет третий шаблон — очень сильно огорчает.

Покажите мне хоть один мало-майски большой проект реализованный на Symfony 2

Полностью на Symfony2:
wetter.com
youporn.com
exercise.com

И еще www.bbc.com используют многие компоненты.

Надеюсь увидеть примеры с yii в ответ. Хотя бы с 1/10 от нагрузки youporn, например. (100 млн просмотров в день)

P.S. Хватит яд лить на оправданные замечания. Требуете уважительного отношения — начните с себя.

Что в этих сервисах большого?
То что они под большой нагрузкой отдают статичный контент? Функционала там большого нет HighLoad c без функционала.
Вы опять же не понимаете для чего существуют framework'и. Они нужны для снижение сложности проекта в разработке и поддержке. Отдача статики тут не при чем.

Вот если взять для примера на Yii: Oyepages.com
Социалка. Вот там функционал нужен и его много.

p.s.
где оправданные замечания, а не вода? Где яд?

exercise.com — это как раз своеобразная соц сеть, превышающая и по траффику и сложности логики ваш oyepages.com. На хабре вроде есть человек, который над ним работает, он бы вам мог подробнее рассказать. Ну и хайлоад — это далеко не «просто отдать статику под нагрузкой», вы в очередной раз свою некомпетентность в вопросе показываете таким заявлением.

Замечания касательно ваших знаний о Symfony2 и его архитектуре. Куда уж быть конкретнее, чем мои ответы, разобранные по пунктам, я не знаю.

Кстати, заметьте, что, в отличие от вас, я ни разу не писал своё мнение касательно yii, хотя опыт работы с ним был немалый. Я понимаю, что это мнение и не совсем актуальное ввиду развития проекта и субъективное, т.к. каждый хвалит свой огород.

Про яд — серьезно? Вы правда настолько не следите за собой, что не замечаете мат, переход на личности и язвительные ремарки?

У меня несколько вопросов:
— как вы оценили сложность логики? (трафик тут вообще не из нашей предметной области, если хотите, то объясню почему)
— почему вы мне рассказываете что у вас есть опыт работу с yii? это же не касается нашей с вами дискуссии.
— где мат с моей стороны? процитируйте пожалуйста

На счет конкретики. Давайте посмотрим ваши первые комментарии и найдем там конкретику. Можете опять же процитировать себя, для наглядности. Я там вижу как правило воду.

Я бы посмотрел все три системы, и прикинул под какую проще и быстрее переделать контроллеры из «самописки».

Симфони наверное всем критериям отвечает, только в него вникать не быстро.

Ну да. По холивару ниже вы должны увидеть, на сколько не быстро. На мой взгляд, отсутствие толкового менеджмента сейчас убивает две неплохих разработки: Симфони проти Уии, и пхпДемон против Ноды.

Причем это провтыкательство чисто на информационном поле. Симофни хороша только в одном: она не дает писать говнокод. Приходится читать как это сделать «правильно». А народ не очень у нас любит читать доки. Тем более на английском. Поэтому так =)
Когда я последний раз выбирал двиг под свой новый проект, выбрал симфони из-за сложности. Она провоцирует получать знания, что для меня, ленивого, достаточно актуально. Зато «зная» как делать, потом уже удивляешься — как можно было до этого писать такие горы самописного кода, когда уже столько написано и протестировано другими.
Для примера, у меня папка Yii (вся) занимает 26Mb
Папка vendor в симфонии — 128. Это код, который написан, отлажен, оттестирован и который за меня исправят, если я найду случайно в нем баги :) Осталось только научиться искать в этих 128 Мб нужные куски кода :) А это ж.па :)