Официальный гайд по лучшим практикам в Symfony

[@Enlightened]

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

[@shoomyst]

Многое зависит от проекта. Я начинал так же с UserBundle, CompanyBundle и еще куча бандлов. Вроде как всё независимо и расширяемо. Но через некоторое время начались непонятки, в какой бандл класть какую логику. В итоге пришел к WebappBundle + ApiBundle -> ApplicationBundle -> DataBundle. Сейчас уже приходит осознание, что надо выпиливать и последние два.

[@AmdY]

Согласен, тем более что есть composer, чтобы следить за этими зависимостями.

[@hell0w0rd]

Есть отделяемые абстрактные компоненты, вроде OAuthBundle, или UserBundle. А есть приложение, в котором Entity\User зависит от других компонентов, банально у User могут быть посты/проекты/статистика и тд. Думаю имеется ввиду помещать в один бандл код, который без дополнительных плясок с бубном нельзя отсоеденить от проекта.
А повторяющийся код — да, хорошо бы выделять в отдельные бандлы.

[@m_z]

А часто ли вы использовали повторно бандлы приложения? На практике проще весь код, связанный с симфони поместить в бандл, а остальное вывести выше, т.е. отделить весь бизнес слой, который можно повторно использовать где угодно и в каком угодно фреймворке. И не будет дилемм куда класть и где искать нужную структуру классов.

[@psylosss]

Добавляйте кнопки в шаблоне, а не в PHP коде.

Этот совет про то, что не надо писать такой код, или имеется в виду что-то другое?

$form->add('submit', 'submit', array('label' => 'Сохранить', 'attr'=>array('class'=>'btn btn-primary')));

[@hell0w0rd]

Да.
Помимо этого я бы добавил, что даже если вы не используете переводы в проекте — вам стоит начать их использовать для форм. Формы автоматом смотрят есть ли перевод и для однотипных названий вроде submit можно прописать перевод один раз и потом не указывать каждый раз label.

[@shoomyst]

Сначала они переделали половину компонента Form для поддержки кнопок, а сейчас просят не использовать их))
Кто как решает эту проблему с лейблами для кнопок Create/Edit? Т.е. в каком месте решается, какой будет label и на основании чего?

[@ramzes_yan]

используйте разные шаблоны

create.html.twig

{% extends "::base.html.twig" %}

{% block body %}
      {{ form(form) }}
      <input type="submit" value="Create">
{% endblock %} 

edit.html.twig

{% extends "::base.html.twig" %}

{% block body %}
      {{ form(form) }}
      <input type="submit" value="update">
{% endblock %} 

как то так

[@Fesor]

Ну я обычно объявляю что-то типа form.html.twig и наследую от него create и edit а кнопки в блок form_buttons но идея в принципе та же.

[@CrazySquirrel]

Чёрт, ребята, подскажите, аннотации только мне не нравятся?

[@hell0w0rd]

А чем вам аннотации не нравятся? У меня есть парочка аргументов против, например сразу не понятно как работает конкретная аннотация, соответсвенно не понятно как она влияет на производительность (привет @Template). Но если внутренности аннотации написаны качественно, подключив плагин в phpstorm с аннотациями работать одно удовольствие.

[@CrazySquirrel]

В основном, мне не нравится идея слияния кода и конфигурации, и как следствие, невозможность найти всю конфигурацию в одном месте.

[@hell0w0rd]

На мой взгляд все как раз наоборот. Если вы используете аннотации в роутах, например, вам достаточно удалить экшн и роут пропадет вместе с ним. Не надо никуда лезть и так далее. Ровно как и с модельками, надо добавить поле — пожалуйста.
Другие варианты конфигурации раскидывают каждую модельку в отдельный файл, в итоге получается что нужно всегда править два файла.
А поиск — возьмите норм ide, с go-to-symbol, опять таки под phpstorm есть отличный плагин для symfony.

[@CrazySquirrel]

Я не спорю с тем, что многие любят аннотации, вопрос заключался в том, кто их не любит :-)

[@shoomyst]

По-моему аннотации это круто, а если их сделают еще и частью языка так, чтобы они не вырезались как комментарии, то вообще будет шикарно.
Но при их использовании надо знать какую-то меру, которая у всех, конечно, разная. Меня, например, несколько удивляет, когда серьезную логику пытаются перенести в аннотации — иногда получается забавно, когда action-ы не содержат ни строчки кода, но зато у каждого по 10 аннотаций :)
Сам использую только Route и JMSDiExtra: не люблю лезть каждый раз в конфиги для этих задач. Для повторно используемых частей приложения, разумеется, всё через конфиги

[@R0ckwi11]

Мне тоже не нравятся. Примерно по тем же причинам

[@hell0w0rd]

Это по каким?

[@hell0w0rd]

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

[@Fesor]

Если писать заведомо качественный код, то его можно переиспользовать

Вам часто доводилось переиспользовать код контроллеров? Бизнес логики в них нету, всяких полезностей которые можно реально переиспользовать там так же нету… Так зачем?

Аннотации как по мне не особо влияют на соблюдение/несоблюдение принципов SOLID. Ну или приведите пример, ибо я вас не понимаю. Чем скажем использование аннотаций типа Route или Method влияют на соблюдение принципа инверсии зависимостей?

[@Fesor]

Ничего мы не теряем, мы просто конфигурацию переносим из yml поближе к определению класса сервиса. Хотя я не вижу в этом особо смысла и мне кажется это даже менее удобным. Авторесолвинг зависимостей по тайп хинтингу был бы намного более удобной штукой.

Что до контроллеров как сервисов, мне к слову интересно по какой причине фабьен не рекомендует такой подход…

[@Fesor]

Также использование этой аннотации замедляет ваше приложение на 21мс.

Видимо в контексте надо почитать, ибо не понятно откуда такие цифры берутся… Вообще аннотации все эти клевые штуки, но это больше для RAD.

[@hell0w0rd]

Не хотел сильно статью захламлять. Контекст такой — взяли простейшее приложение (BlogApp) и замерили, $twig->render() быстрее @Template на 21 мс

[@wait]

Это и странно:
заглянул в TemplateListener — не увидел ничего страшного: угадывание путей шаблона и вызов render();
проверил несколько раз скорость работы с @Template и без — абсолютно равны;
выключил целиком TemplateListener (sensio_framework_extra.view.annotations: false) — тоже ничего не изменилось;

Конечно, какой-то оверхед присутствует (то же угадывание путей шаблонов), но в целом описанная в документе разница (5 мс и 26 мс) недостижима.

[@Fesor]

Строго говоря, да, но согласитесь, эта аннотация умеет сама определять какой шаблон вы хотите отрендерить на основе того какой экшен контроллера выполняется. То есть грубо говоря используя эту аннотацию без каких либо параметров мы просто говорим фреймворку «мне лень, сделай это за меня».

[@m_z]

Не используйте аннотацию @Template()

А альтернатива какая? Писать каждый раз имя шаблона утомительно.

PS: «Контроллеры приложения должны наследовать Symfony\Bundle\FrameworkBundle\Controller\Controller» это точно Fabian там?

[@shoomyst]

А что не так? Если его позиция за последнее время не изменилась, то он настаивает на несервисных контроллерах

[@m_z]

Ну его позицию не знаю, но это же не запись с его блога, а документ на сайте симфони с громким названием. Хотелось бы, чтобы все пункты были объективны, а не аргументации в виде «no benefits when using controllers as services» и premature optimization.

[@Akuma]

> Храните ваши шаблоны в директории app/Resources/views/.
Немного не понял. Это призыв не хранить шаблоны внутри бандла, а выносить их отдельно?

[@hell0w0rd]

В целом вообще призыв, как я понял — исключить Resources из AppBundle. Я сходу не понял, предрагается также вынести все DI в app/config/services.yml.

[@Akuma]

Довольно жуткий совет, как мне кажется.

[@hell0w0rd]

Почему?

[@Akuma]

Раз уж бандл — независимая еденица, то не стоит отделять от него шаблоны. Хотя бы поэтому.

[@wait]

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

For starters, this drastically simplifies their logical names

для начинающих: сильно упрощает наименование файлов (default/index.html.twig вместо AcmeDemoBunde:Default:index.html.twig)

Another advantage is that centralizing your templates simplifies the work of your designers. They don't
need to look for templates in lots of directories scattered through lots of bundles.

упрощает поиск шаблонов для дизайнеров.

Как по мне — так оба довода сомнительны.

[@hell0w0rd]

А есть вообще удачные билд-системы для фронтенда не на nodejs? Просто если нужно что-то сложное — сразу появляются костыли, которых как раз и стоит избегать разделением проекта.

[@Fesor]

А что плохого в node.js? Я вот вообще выкинул assetic и phing и заменил на gulp. node.js при таком подходе нужно только на билд сервере ставить а в билд попадают только уже подготовленные файлики.

[@Akuma]

Да, я тоже «заметил» этот совет про два проекта. Хотя не особо представляю как это.
И тем не менее, я согласен, что разрабатывать одновременно на Angular и Symfony довольно проблематично, если хочется использовать какие-либо системы сборки и прочие плюшки.

[@shoomyst]

Что-то не открывается сейчас их pdf

An unexpected error occurred (error code: 500).

Если кто скачал себе, можете перезалить куда-нибудь?

[@hell0w0rd]

www.dropbox.com/s/vrjc6wept1kz62k/symfony-best-practices.pdf?dl=0
Это черновая версия. Следите за оригинальной ссылкой.