Приходилось тыкать в go и шарпе. И таки да, как по мне, эта фича больше способствует лапшекоду, нежели набор вменяемых классов (естественно при создании анонимных будет сильно хуже, чем с async/await) наблюдателей.
Видимо у меня устаревшая информация, кстати с хабра (увидел, разочаровался, стал ждать пока поправят и забыл). Что ж я только рад, теперь надо только ждать миграции всего и вся на эту вещь.
Вот такой вот я больной :) Просто если не охота с ними возиться, то и не нужно, есть решения которые это делают сами, а коли уж понадобилось, так пусть у меня будет полный контроль и без лапши в коде.
В механизме управления и «явственности». Ну это опять-таки просто дело вкуса.
Штука конечно замечательная, но пых просто сожрёт всю память и на этом всё закончится (слишком много утечек в ядре, т.к. не рассчитан пых на такую работу)
Я не против многопоточности в пыхе, я просто против её реализации через async/await. А так это всё пока не очень-то актуально, вот когда я смогу запускать пыху, а не наблюдать как она запускается, отрабатывает и умирает, вот тогда уже можно будет нормально подискутировать о многопоточности, иначе оно просто не имеет смысла.
Мне просто шарп как вид не очень мил. Моему сердцу родней пачка наблюдателей, а не сигналы/слоты, да и управление многопоточностью я привык оставлять на akka и при необходимости разруливать с тредами, а не лапшой с async/await.
Тезис был больше про вложенные классы, а анонимные — приятное дополнение.
Касательно объектов в константах (в пыхе так нельзя, но ОЧЕНЬ хочется):
<?php
class Example
{
private final static $logger = new Logger(__CLASS__);
private $someSimpleDependency = new SimpleDependency();
public function doSomething(Argument $argument = new Argument())
{
}
}
class Enum
{
const SOME_VALUE = new self('some value);
// ...
}
Это не единственное, чем ява 8 шарпу нос утёрла, ещё монады появились :). Я бы не стал использовать эту фичу в этих целях…
Пых-таки ближе к яве и я был бы не прочь, если бы он продолжал шагать в эту сторону, в конце концов иметь яву с поздним статическим связыванием и опциональной динамической типизацией — есть хорошо, настолько же, насколько хорошо иметь пых с вложенными и анонимными классами, областью видимости для классов в пространствах имён, дефолтной реализацией интерфейсов, и чего больше всего сейчас не хватает: объектами в константах… Эх, что-то я совсем размечтался.
Классно конечно, для шарп-разработчиков, но в целом ориентирование на веб-разработку (JS, node) не самая логичная идея (<-каламбур), ведь есть уже крутая IDE на эту тему от JetBrains (WebStorm) и переплюнуть её — проблематично.
Однако если упор будет в сторону шарп-разработки, то я доволен, ещё б поддержку разработки под винфон запилили и цены б им не было (наболело, очень уж лень ставить windows ради этого).
Вы, конечно, молодец, что пытались написать статью о Symfony не используя тучи терминов, но IMHO лучше не подпускать к «взрослым фреймворкам» (и тем более не пытаться объяснять все «за» и «против») людей, которые понимают меньше ~70% этих терминов. В противном случае в коде внезапно может оказаться лишний (aka бесполезный) слой абстракций над стандартным функционалом или отмазы от использования готовых решений с мотивацией «заказчик не велел использовать {библиотеку, фреймворк} X» (и это-то на фрилансе), в худшем же случае может появиться что-то такое или даже такое. (и да это всё примеры из жизни)
К тому же, термины — это тоже просто абстракция (да-да вспоминаем, что паттерны задумывались как словарь) которая сокращает количество слов необходимых для передачи смысла. А т.к. это всё-таки хабр, то аудитории, которая это читает, следует быть готовыми к такой терминологии.
Не буду расписывать код, но если просто на словах, то:
Есть проект в котором существенны сложные курсы валют, т.е. код валюты, название валюты (просто подгружается из API центробанка), добавочный процент (итоговые записи для пользователя — «CBE + 5%»), собственно сам курс (тоже из API) и дата. Вот как раз эту логику я был бы очень не прочь вынести в VO, но пока это реализовано через наследование от некоторого CurrencyHolder и это здоровенный костыль. И да это не Money, ибо здесь нет собственно количества.
Есть другой проект, где пользователь имеет несколько кошельков (разные неконвертируемые внутренние деньги), на текущий момент это реализовано через то самое место: 4 метода — «payWithCoins(amount)», «payWithDollars(amount)», «replenishCoins(amount)», «replenishDollars(amount)». Но это лучше вынести в 2 VO, реализующих некоторый «WalletInterface» и код станет значительно чище (на 400 строчек меньше в классе пользователя, уберутся use-ы класса пользователя, оттуда где от него требуется только кошелёк и т.д.). Кстати, в этом случае валидацию на количество денег я бы сделал через исключения, а не через "@Assert" и это было бы очень даже логично.
Некогда было пытаться выяснить можно ли доктрину мапнуть к полю трейта + это не решило бы проблему использования класса пользователя в тайп хинтах, где нужны лишь несколько его методов, а тогда тем более было не до создания/выделения интерфейсов.
Действительно, после модификации объекта даты «spl_object_hash» возращает то же значение, что и до неё.
Symfony, вернее ее документация и ее сообщество провоцирует людей на оверинжениринг. А вообще какие могут претензии к набору байтов? Нужно рассматривать явление в целом.
Кхм, можно выдержку из документации? Я бы назвал это не «оверинженеринг», а дрессировкой до понимания концепций программирования в целом (при условии какая общая масса пишет на PHP — это необходимо), а когда человек понимает, что он вполне разобрался, то он лезет в «Best Practice», где чёрным по белому написано избегать лишней сложности. Что касается явления, то может стоит критиковать его, а не «чрезмерную сложность» Symfony?
Вот именно поэтому я ее написал. И отдельно выделил абзац Symfony-only developer, потому что за счет перерывов в работе «со-стороны» мне были особенно заметны сложности, возникающие с этим фреймворком.
Тут бы важно уточнить с какой стороны, мне бы тоже пожалуй казалось что всё в императивных языках слишком сложное, трудное к запоминанию и запутанное, попиши я годик-другой на хаскеле. Тут вопрос точки зрения, и невозможно сказать точно какая из них объективна. Прям «Здоровое Общество» Фромма…
По-моему опыту на сколь угодно проблемном языке и фреймворке можно эффективно работать, если «привыкнуть», и многие склонны путать привыкание с эффективностью самой технологии.
Так а в чём тогда проблема-то? Если можно эффективно работать, создавая вменяемый код, пусть даже и под действием «привыкания», то все ведь должны быть довольны, разве нет?
Там наконец добавили ValueObject, теперь, наконец, не придётся делать из класса пользователя швейцарский нож.
Что касается монструозности и т.п., радует что оно не единомоментно разом всё грузится, да ещё и с кешем.
Что касается отвратительности и неочевидности: можете привести пример? (просто на моей памяти она себя так ведёт только с глубоко вложенными коллекциями, там с ленивостью немного переборщили, что приходится общаться с PersistentCollection и Proxy на сущность напрямую, дабы загрузить некоторые данные + весёлый баг больше относящийся к кодогенератору, но всё же: забираем дату, меням, запихиваем, пытаемся сохранить и получаем кукиш ибо это один и тот же объект и UnitOfWork посчитал его не изменившимся, а решается проблема через clone в аксессорах)
Вы правы, для простых форм Forms идеальны и экономят много времени на создание крудов к моделям. На больших формах все уже не так однозначно — зависит от наличия динамических полей.
Чтож это так, но не стоит их обливать по чём зря, при условии, что динамические поля являются проблемой абсолютно везде.
Опять же, для простых крудов доктрина хороша. Для сложных запросов уже придется помучаться с DQL, для использования хранимок тоже придется с ним помучаться.
Не припомню запроса, где бы с я мучался с доктриной, скорее наоборот, она частенько спасает. Что же касается хранимок, не буду врать в реальной жизни мне не приходилось с ними сталкиваться, более того я даже не могу представить ситуацию в которой они бы мне пригодились, но тем не менее ничто не мешает их использовать через нативные запросы с каким-нибудь хитрым гидратором. И опять-таки всё свелось к тому, что доктрина не плохая, а просто не идеальна (что собственно вполне логично).
Если вы почитаете комментарии, то увидите, что люди ставят в плюс Symfony готовую структуру и предсказуемость кода, и если я буду лепить нечто свое поверх фреймворка, то это будет встречено крайне неоднозначно. Вы можете менять фреймворк на свое усмотрение только в двух случаях: если вы тимлид или если вы пишите проект в одиночку.
Тут вы правы, но может тогда стоит выдвигать претензии не к инструменту, а к тимлиду, т.е. нормально с ним поговорить о существующих проблемах, сотворить решение, задокументировать в Confluence или другой местной вики и радоваться жизни?
Вы пишите еще на чем-то кроме PHP и Symfony? Так чтобы не на уровне hello-world и вводных туториалов. Если пишите, и у вас при этом все не вылетает из головы, то могу только позавидовать вашей памяти.
Ну, для начала к чему этот вопрос? Если вы не постоянный разработчик на Symfony или даже PHP, то зачем вообще было писать эту статью? Но тем не менее: да помимо Symfony я вполне способен писать на codeigniter, vanilla; помимо PHP я достаточно активно пишу на JS (но как видно по рейтингу моей статьи, это нужно только мне :) ), без bash/shell/zsh + grep/sed мне в принципе трудно живётся, ну и наконец я изредка пишу на lua и это только то, что не на уровне «потыкать ради интереса», а немного серьёзнее, и да я большую часть названий методов/классов/… помню + я достаточно не плохо помню синтаксис десятка языков программирования/разметки. Но речь ведь не о том, самое важное, что я помню как что делать в Symfony+PHP, не забывая при этом, например, angular или socketIO. А в целом эта претензия может быть с тем же успехом предъявлена к абсолютно любому, хоть сколько-то большому, инструменту.
Бойлерплейт также усложняет восприятие кода — меньше кода, проще читать. Кстати вам известно в каких случаях в 2.3 репозитории генерируются по doctrine:generate:entities, а в каких — нет? Только честно, не гугля.
Это не тот объём + что вам мешает сотворить один контроллер как сервис и делегировать ему весь CRUD для всех простых сущностей меняя лишь роуты в конфиге? К тому же, для быстрого разбора в хорошо написанном коде (т.е. без сохранения сущностей внутри FormTypeInterface::buildForm()) совсем не сложно разобраться в коде просто пробежавшись по структуре классов через встроенные средства IDE.
Не встречал случая, чтобы они вообще генерировались при этой комманде, хотя этому есть разумное объяснение: Я не использую эту комманду, как минимум потому, что мне не сложно при описании новой сущности потыкать Alt+Enter и Enter на «Generate accessors...» + это не создаст путаницы у меня в комментариях к методам (не переношу длинные записи названий типов [integer, boolean]).
Совершенно верно. Только assetic это де-факто стандарт. Его знают все, он во всех легаси проектах, он используется и в новых проектах, когда люди думают, что проект не вырастет. В общем от ассетика часто никуда не деться.
В таком случае это всё же не проблема ассетика, а проблема legacy (частенько это наименьшая проблема в втаких проектах). Но от него совсем просто можно отказаться и перейти на gulp или что-либо ещё, ведь выпилить из кода все вхождения "{% javascripts %}"/"{% stylesheets %}" совсем не сложно, даже простой регуляркой.
Замечательно, что вы читали Фаулера. Судя по тому, что помните размер и название глав, делали это недавно. Теперь удосужтесь потратить хотя бы год, чтобы уложилось в голове, а потом еще несколько лет, чтобы вдумчиво разобраться всегда ли стоит их городить. Я не спорю, что такие вещи как IdentityMap и UnitOfWork это важно, но с тем, что их реализация нужна значительному числу пользователей Doctrine, вынужден не согласиться.
Читал я его примерно год назад, а объём помнится из-за сложности тем, что касается названий глав это необходимый словарь, посему я его достаточно неплохо помню. Никто не спорит, что злоупотребление паттернами есть зло, иногда даже худшее, чем антипаттерны, но я же не предлагаю создавать блокировки для однопользовательской системы и тем более не предлагаю использовать IdentityMap для хранения скаляров в яве ради оптимизации, не говоря уже о SpecialCase для каждого состояния объекта.
Да, для немалой части операций с данными в PHP это оверкилл, но этот оверкилл окупается за счёт того небольшого процента сэкономленных запросов к БД (помним что это стоит дорого) и чрезвычайно удобного управления объектами. И опять-таки это из разряда «не идеального», а не плохого + Symfony тут прямо скажем не причём.
Верно, но вам все равно придется знать дефолтные компоненты Symfony и костыли к ним, потому что если вы придете на собеседование по Symfony и скажете, что вместо Doctrine вы использовали например Idiorm, то ваши шансы на прием на работу уменьшаться.
Это уже зависит от работодателя.
Не припоминаю необходимости пилить какие-либо костыли.
С каких это пор в мире ИТ стало модно мало знать?
Зато представьте, какой бонус вам будет, если на собеседовании вы скажете что умеете использовать и Doctrine, и Idiorm, и Propel, да ещё и в курсе в каком случае что лучше использовать и где какие есть проблемы и тем более понимаете как это всё прикрутить к симфони!
Собственно претензия больше к людям, а не к инструментам, я вас правильно понимаю?
Если вы не соврали относительно вашего года рождения, то скорее всего Symfony — ваш первый фреймворк, или же первый среди тех, в какие вы серьезно вникали. Или у вас было относительно немного проектов и мест работы, в которых Symfony более менее подходил. Если нет, то поделитесь пожалуйста информацией о том сколько и где вы его использовали.
Я не вижу смысла врать, тем более так. Symfony — мой первый «взрослый» фреймворк, были попытки и на CodeIgniter (Я честно пытался вникнуть в него, но он слишком «не то»), и на Yii (как раз перед Symfony, вот как раз тогда ваш комментарий был бы актуален [его хотелось радостно защищать и восхвалять, пока не наткнулся на проблемы с поддержкой и беды с БД]), и попытки «потыкать» Laravel (уже после Symfony, пары старых умных книг, осознания ООП и паттернов), и попытки написать свои велосипеды (куда ж без этого); у всего этого лишь один плюс — опыт + я выработал для себя идеальный способ изучения новых технологий. Что касается опыта использования Symfony — он не так велик, всего с пяток коммерческих проектов (1 — legacy, 2 — CRUD, 2 — много бизнес логики, много данных) + разнообразная лабуда для личного интереса + изучение исходников FOSUserBundle + дохлые попытки портировать некоторые наиболее интересные куски Symfony для NodeJS (мало толку для ноды, но много толка для понимания работы Symfony), но пока все трудности решались чуть более вдумчивым чтением документации.
Как итог: какие у вас претензии конкретно к Symfony, не к доктрине, не к людям, которые не дают вам достаточно свободы для продуктивной работы, не к legacy-проектам, где нагорожено непойми что, и удивительно как оно вообще работало, а конкретно к Symfony?
Дело не в нормальности/ненормальности, а в здравом смысле:
— те же, ненавидимые вами, формы можно радостно использовать и для быстрого написания CRUD, и для REST-сервисов, и для действительно сложных динамических форм без особых проблем;
— про то, как доктрина упрощает жизнь вероятно даже говорить не стоит, как-никак DataMapping всегда был лучше конкурентов в ORM, а ежели не согласны, то попробуйте-ка прикрутить Bidirectional Many-To-Many к ActiveRecord в том же самом Yii (да это была одна из причин перехода на Symfony, ибо вменяемо к Yii прикрутить что-либо практически невозможно, да даже с их extensions);
— даже при том, что GodObject это плохо, вам ни что не мешает сотворить его в Symfony (Singleton как сервис с call на метод установки контейнера), другой вопрос что проект через год будет проще переписать, чем рефакторить/поддерживать (что и случается с Yii{1,2}/Laravel);
— про память: не можете запомнить как создать репозиторий (простое наследование + одна аннотация/строчка в конфиге), добавить роль (просто одна строчка в конфиге, с содержимым в виде названия этой роли), добавить трансформер (реализовать один интерфейс), обявить сервис (даже IDE это умеет через 2 клика), написать комманду (наследование + реализация целых двух методов)? У меня для вас плохие новости…
— про бойлерплейт: не хотите писать очередной CRUD? Не проблема, возможно открою тайну, но есть замечательные стандартные кодогенераторы!
— тормозит Assetic при использовании бутстрапа из less + десятка файлов с bower-a? Может дело не в нём, а в вас? Может не стоит смешивать backend и frontend в крупном проекте? Может проще написать отдельно RESTFull backend и одностраничный frontend на angular/ember/...?
— не нравится сложность аннотирования доктрины при создании табличного наследования? Бегом читать дядюшку Фаулера, да-да те 3 здоровые главы, вторые по объёму после блокировок + сами блокировки + IdentityMap + UnitOfWork + MetadataMapping + ..., а после осознания прочитанного, думаем ещё раз на тему «Так ли сложно прописать две аннотация, чтоб доктрина сделала всё за меня?»! Да, и вспоминая Yii, не напомните есть ли там такое вообще?
— про «возможность измения только на бумаге» (ветка ниже): заменить можно (!) любой компонент, не сильно много усилий прилагая (спасибо DI), другой вопрос нужно ли это или это просто очередной случай невнимательного чтения документации?
— ну и наконец про порог вхождения и сложность: это не у Symfony высокий порог вхождения, а у PHP низкий, любой нормальный программист, знакомый с ООП не только как с расшифровкой, способен писать на Symfony после (!) недели вкуривания документации, а ежели ещё и с SOA знаком, то после пары дней, а в некоторых случаях сразу (IDE — наше всё). А вот фреймворки с одним God-Singleton-ом (Yii 1) или десятком статических фасадов/singleton-ов (Yii 2 / Laravel) способствуют написанию неподдерживаемого быдлокода, хоть и идеальны для новичков (крайне низкий порог вхождения, ООП знать совсем не обязательно чтоб на них писать [личный опыт]). Отсюда и понятия «взрослых» фреймворков: Zend / Phalcon / Symfony, где большей частью возрастом нужно считать опыт программиста.
В механизме управления и «явственности». Ну это опять-таки просто дело вкуса.
Тезис был больше про вложенные классы, а анонимные — приятное дополнение.
Касательно объектов в константах (в пыхе так нельзя, но ОЧЕНЬ хочется):
Это не единственное, чем ява 8 шарпу нос утёрла, ещё монады появились :). Я бы не стал использовать эту фичу в этих целях…
CodeStyle,Naming,OOP).Вам следует почитать про шаблон интерпретатор, AST, BNF и оптимальные способы «приписывания» цифры к числу (запомните: строки в оптимизации — ЗЛО)
На вкус и цвет все фломастеры разные.
Однако если упор будет в сторону шарп-разработки, то я доволен, ещё б поддержку разработки под винфон запилили и цены б им не было (наболело, очень уж лень ставить windows ради этого).
К тому же, термины — это тоже просто абстракция (да-да вспоминаем, что паттерны задумывались как словарь) которая сокращает количество слов необходимых для передачи смысла. А т.к. это всё-таки хабр, то аудитории, которая это читает, следует быть готовыми к такой терминологии.
Действительно, после модификации объекта даты «spl_object_hash» возращает то же значение, что и до неё.
Тут бы важно уточнить с какой стороны, мне бы тоже пожалуй казалось что всё в императивных языках слишком сложное, трудное к запоминанию и запутанное, попиши я годик-другой на хаскеле. Тут вопрос точки зрения, и невозможно сказать точно какая из них объективна. Прям «Здоровое Общество» Фромма…
Так а в чём тогда проблема-то? Если можно эффективно работать, создавая вменяемый код, пусть даже и под действием «привыкания», то все ведь должны быть довольны, разве нет?
Что касается монструозности и т.п., радует что оно не единомоментно разом всё грузится, да ещё и с кешем.
Что касается отвратительности и неочевидности: можете привести пример? (просто на моей памяти она себя так ведёт только с глубоко вложенными коллекциями, там с ленивостью немного переборщили, что приходится общаться с PersistentCollection и Proxy на сущность напрямую, дабы загрузить некоторые данные + весёлый баг больше относящийся к кодогенератору, но всё же: забираем дату, меням, запихиваем, пытаемся сохранить и получаем кукиш ибо это один и тот же объект и UnitOfWork посчитал его не изменившимся, а решается проблема через clone в аксессорах)
Не припомню запроса, где бы с я мучался с доктриной, скорее наоборот, она частенько спасает. Что же касается хранимок, не буду врать в реальной жизни мне не приходилось с ними сталкиваться, более того я даже не могу представить ситуацию в которой они бы мне пригодились, но тем не менее ничто не мешает их использовать через нативные запросы с каким-нибудь хитрым гидратором. И опять-таки всё свелось к тому, что доктрина не плохая, а просто не идеальна (что собственно вполне логично).
Тут вы правы, но может тогда стоит выдвигать претензии не к инструменту, а к тимлиду, т.е. нормально с ним поговорить о существующих проблемах, сотворить решение, задокументировать в Confluence или другой местной вики и радоваться жизни?
Ну, для начала к чему этот вопрос? Если вы не постоянный разработчик на Symfony или даже PHP, то зачем вообще было писать эту статью? Но тем не менее: да помимо Symfony я вполне способен писать на codeigniter, vanilla; помимо PHP я достаточно активно пишу на JS (но как видно по рейтингу моей статьи, это нужно только мне :) ), без bash/shell/zsh + grep/sed мне в принципе трудно живётся, ну и наконец я изредка пишу на lua и это только то, что не на уровне «потыкать ради интереса», а немного серьёзнее, и да я большую часть названий методов/классов/… помню + я достаточно не плохо помню синтаксис десятка языков программирования/разметки. Но речь ведь не о том, самое важное, что я помню как что делать в Symfony+PHP, не забывая при этом, например, angular или socketIO. А в целом эта претензия может быть с тем же успехом предъявлена к абсолютно любому, хоть сколько-то большому, инструменту.
В таком случае это всё же не проблема ассетика, а проблема legacy (частенько это наименьшая проблема в втаких проектах). Но от него совсем просто можно отказаться и перейти на gulp или что-либо ещё, ведь выпилить из кода все вхождения "{% javascripts %}"/"{% stylesheets %}" совсем не сложно, даже простой регуляркой.
Я не вижу смысла врать, тем более так. Symfony — мой первый «взрослый» фреймворк, были попытки и на CodeIgniter (Я честно пытался вникнуть в него, но он слишком «не то»), и на Yii (как раз перед Symfony, вот как раз тогда ваш комментарий был бы актуален [его хотелось радостно защищать и восхвалять, пока не наткнулся на проблемы с поддержкой и беды с БД]), и попытки «потыкать» Laravel (уже после Symfony, пары старых умных книг, осознания ООП и паттернов), и попытки написать свои велосипеды (куда ж без этого); у всего этого лишь один плюс — опыт + я выработал для себя идеальный способ изучения новых технологий. Что касается опыта использования Symfony — он не так велик, всего с пяток коммерческих проектов (1 — legacy, 2 — CRUD, 2 — много бизнес логики, много данных) + разнообразная лабуда для личного интереса + изучение исходников FOSUserBundle + дохлые попытки портировать некоторые наиболее интересные куски Symfony для NodeJS (мало толку для ноды, но много толка для понимания работы Symfony), но пока все трудности решались чуть более вдумчивым чтением документации.
Как итог: какие у вас претензии конкретно к Symfony, не к доктрине, не к людям, которые не дают вам достаточно свободы для продуктивной работы, не к legacy-проектам, где нагорожено непойми что, и удивительно как оно вообще работало, а конкретно к Symfony?
— те же, ненавидимые вами, формы можно радостно использовать и для быстрого написания CRUD, и для REST-сервисов, и для действительно сложных динамических форм без особых проблем;
— про то, как доктрина упрощает жизнь вероятно даже говорить не стоит, как-никак DataMapping всегда был лучше конкурентов в ORM, а ежели не согласны, то попробуйте-ка прикрутить Bidirectional Many-To-Many к ActiveRecord в том же самом Yii (да это была одна из причин перехода на Symfony, ибо вменяемо к Yii прикрутить что-либо практически невозможно, да даже с их extensions);
— даже при том, что GodObject это плохо, вам ни что не мешает сотворить его в Symfony (Singleton как сервис с call на метод установки контейнера), другой вопрос что проект через год будет проще переписать, чем рефакторить/поддерживать (что и случается с Yii{1,2}/Laravel);
— про память: не можете запомнить как создать репозиторий (простое наследование + одна аннотация/строчка в конфиге), добавить роль (просто одна строчка в конфиге, с содержимым в виде названия этой роли), добавить трансформер (реализовать один интерфейс), обявить сервис (даже IDE это умеет через 2 клика), написать комманду (наследование + реализация целых двух методов)? У меня для вас плохие новости…
— про бойлерплейт: не хотите писать очередной CRUD? Не проблема, возможно открою тайну, но есть замечательные стандартные кодогенераторы!
— тормозит Assetic при использовании бутстрапа из less + десятка файлов с bower-a? Может дело не в нём, а в вас? Может не стоит смешивать backend и frontend в крупном проекте? Может проще написать отдельно RESTFull backend и одностраничный frontend на angular/ember/...?
— не нравится сложность аннотирования доктрины при создании табличного наследования? Бегом читать дядюшку Фаулера, да-да те 3 здоровые главы, вторые по объёму после блокировок + сами блокировки + IdentityMap + UnitOfWork + MetadataMapping + ..., а после осознания прочитанного, думаем ещё раз на тему «Так ли сложно прописать две аннотация, чтоб доктрина сделала всё за меня?»! Да, и вспоминая Yii, не напомните есть ли там такое вообще?
— про «возможность измения только на бумаге» (ветка ниже): заменить можно (!) любой компонент, не сильно много усилий прилагая (спасибо DI), другой вопрос нужно ли это или это просто очередной случай невнимательного чтения документации?
— ну и наконец про порог вхождения и сложность: это не у Symfony высокий порог вхождения, а у PHP низкий, любой нормальный программист, знакомый с ООП не только как с расшифровкой, способен писать на Symfony после (!) недели вкуривания документации, а ежели ещё и с SOA знаком, то после пары дней, а в некоторых случаях сразу (IDE — наше всё). А вот фреймворки с одним God-Singleton-ом (Yii 1) или десятком статических фасадов/singleton-ов (Yii 2 / Laravel) способствуют написанию неподдерживаемого быдлокода, хоть и идеальны для новичков (крайне низкий порог вхождения, ООП знать совсем не обязательно чтоб на них писать [личный опыт]). Отсюда и понятия «взрослых» фреймворков: Zend / Phalcon / Symfony, где большей частью возрастом нужно считать опыт программиста.
Всё, я выговорился, можете минусовать.