Comments 21
Я вот прочитал первую статью, вторую…
В голове крутиться одна мысль — ну, отвязал автор контроллеры от фреймворка. В экшнах контроллеры всё равно хавают тот-же HttpFoundation\Request и пр.
Какая от этого реальная польза, кроме как «разобраться, что это за магия»?
В голове крутиться одна мысль — ну, отвязал автор контроллеры от фреймворка. В экшнах контроллеры всё равно хавают тот-же HttpFoundation\Request и пр.
Какая от этого реальная польза, кроме как «разобраться, что это за магия»?
Во-первых, на HttpFoundation уже не только Symfony живет, вот, кажется, Laravel тоже на этот компонент переехал. Так что мы уже не от фреймворка будем зависеть, а от компонента фреймворка.
Во-вторых, в третьей статье серии автор рассматривает отвязку и от HttpFoundation тоже, при помощи выделения дополнительной прослойки.
Во-вторых, в третьей статье серии автор рассматривает отвязку и от HttpFoundation тоже, при помощи выделения дополнительной прослойки.
Абсолюно идиотский подход. С таким подходом можно взять чистый php — никаких зависимостей, полная свобода. А лучше взять плюсы. И скорость, и прибиндить к php/js/ruby/python можно.
Вместо 2-3 аннотаций нужно написать конфигов строк 30 и лишнего кода строк 10, ну шикарно че. Вдруг завтра с симфони на Yii перейдем!
Вместо 2-3 аннотаций нужно написать конфигов строк 30 и лишнего кода строк 10, ну шикарно че. Вдруг завтра с симфони на Yii перейдем!
Ну, насчет чистого PHP вы конечно загнули. Как минимум придется реализовать свой DIC, persistence layer и шаблонизатор.
А про «идиотский подход» — ну так, знаете, автор и не утверждает, что это единственно верный путь разработки, он просто показывает, что типичный уровень связанности в Sf2-приложении совершенно необязателен; хотите — отказываетесь от аннотаций, хотите — от ContainerAware, но никто вас это все сразу делать не обязывает.
А про «идиотский подход» — ну так, знаете, автор и не утверждает, что это единственно верный путь разработки, он просто показывает, что типичный уровень связанности в Sf2-приложении совершенно необязателен; хотите — отказываетесь от аннотаций, хотите — от ContainerAware, но никто вас это все сразу делать не обязывает.
Может быть, переводчик оставит свой комментарий, с какой целью он это перевёл?
Я просто никак не пойму сакрального смысла — зачем начинать использовать какой-то инструмент, чтобы усиленно «отвязываться» от тех преимуществ, которые он даёт
Я просто никак не пойму сакрального смысла — зачем начинать использовать какой-то инструмент, чтобы усиленно «отвязываться» от тех преимуществ, которые он даёт
Бывает так, что проект растёт и развивается и текущий инструмент перестаёт удовлетворять нужды. Поэтому переносят его на что-то более гибкое или современное. Такие вещи начинаешь ценить именно при переносе проекта, конечно если остаётся основной стек технологий при этом.
Но как показала практика, в нашем случае, такие вот привязки к фреймворку отнимают немного врмени, чтобы их перенести. Намного больше занимают формы или шаблоны, при смене технологии или фреймворка…
Но как показала практика, в нашем случае, такие вот привязки к фреймворку отнимают немного врмени, чтобы их перенести. Намного больше занимают формы или шаблоны, при смене технологии или фреймворка…
Ну норм, отвязали слой бизнес-логики от контроллеров и переносите когда угодно и куда угодно. А формы, обработку request, csrf, шаблоны, роутинг, контроллеры — оставляйте фреймворку, он для этого создан.
Ну и я живо себе представляю перенос таких контроллеров на какой-нибудь Silex или еще хуже ZendFramework, в котором, скажем, свои формы, которые ни разу не совместимы с SymfonyForm
Позвольте, так ведь автор и не отказывается от каких-либо преимуществ, он наоборот выделяет преимущества неочевидные.
Так, например, очень многие разработчики наследуют свои контроллеры от базового класса, а значит, и от
Прелесть тут в том, что гибкость Symfony дает несколько путей реализации по сути одного и того же функционала, и в зависимости от случая, вы сможете использовать любой из них. Или аннотации, или конфиги; или ContainerAware-контроллеры, или контроллеры как сервисы — выбор всегда за вами, и зависит от вашей задачи.
Так, например, очень многие разработчики наследуют свои контроллеры от базового класса, а значит, и от
ContainerAware в то время, когда практика выделения контроллеров в сервисы может заметно упростить понимание того, каковы зависимости контроллера.Прелесть тут в том, что гибкость Symfony дает несколько путей реализации по сути одного и того же функционала, и в зависимости от случая, вы сможете использовать любой из них. Или аннотации, или конфиги; или ContainerAware-контроллеры, или контроллеры как сервисы — выбор всегда за вами, и зависит от вашей задачи.
Мне кажется автор этих статей как-то неправильно понял framework-agnostic подход при разработке веб-приложений. Мне кажется речь о том, что слой бизнес-логики не должен зависеть от фреймворка, а не контроллеры. Должны быть сервисы там всякие, уровень домена — они должны быть framework-agnostic, чтобы можно было взять, скажем, и перетащить приложение с symfony на silex+angular. Но тащить готовые контроллеры между фреймворками?? Извините, это какая-то наркомания.
Фух. Я сначала было подумал, что с утра чего то не догоняю, но судя по комментариям, все норм)
На мой взгляд, аннотации как раз увеличивают читаемость и переносимость кода. Вот избавились от аннотаций, понаписали лишнего кода, который будет как раз несовместим с другими фреймворками.
И вообще, контроллеры — это такой тонкий связной слой, в котором не должно быть бизнес-логики (хорошо написано в этой статье: habrahabr.ru/post/175465/), а потому не нужно их «отвязывать», а необходимо именно грамотно раскидывать функциональность по слоям, и тогда решение задачи «сменить фреймворк» сведется в идеале на переименование классов и минимально-механическая адаптация к особенностям нового фреймворка с выкидыванием атавизмов от старого.
И вообще, контроллеры — это такой тонкий связной слой, в котором не должно быть бизнес-логики (хорошо написано в этой статье: habrahabr.ru/post/175465/), а потому не нужно их «отвязывать», а необходимо именно грамотно раскидывать функциональность по слоям, и тогда решение задачи «сменить фреймворк» сведется в идеале на переименование классов и минимально-механическая адаптация к особенностям нового фреймворка с выкидыванием атавизмов от старого.
Добавлю, что магии стало больше в разы. Вместо того что бы увидеть достаточно понятный код в виде аннотаций, мы видим какие то магические инжекты с которыми еще нужно постараться разобраться. В случае необходимости исправить код в таком варианте нужно править как минимум в двух местах. Кроме этого я не понимаю выигрыша от таких действий.
Я могу вам на это сказать, что выделенные в отдельные файлы конфигурации тоже заметно упрощают восприятие кода в целом. Да, удобно бывает с
@Route-аннотациями прямо в контроллере, но точно так же удобно и хранить те же роуты в отдельном конфигурационном файле. Вопрос, во-первых, привычки, во-вторых — проекта.
Эти статьи можно использовать для введения в Symfony новичков. Начинаешь им показывать как использовать симфони, но исключив на начальном этапе некоторые вещи:
А потом уже начать вводить аннотации из FrameworkExtraBundle, начинаешь использовать обертки из FrameworkBundle\Controller и показываешь преимущества использования твиг-шаблонов. В похожем ключе рассказывал у себя в конторе про симфони другим разработчикам достаточно успешно, даже черновики докладов остались.
- не использования sensio/framework-extra-bundle
- контроллеры наследовать не от FrameworkBundle\Controller, а сразу от ContainerAware
- вместо твига — пхп шаблоны
А потом уже начать вводить аннотации из FrameworkExtraBundle, начинаешь использовать обертки из FrameworkBundle\Controller и показываешь преимущества использования твиг-шаблонов. В похожем ключе рассказывал у себя в конторе про симфони другим разработчикам достаточно успешно, даже черновики докладов остались.
Да-да-да, полностью с вами согласен. У Бенджамина Эберлея про это статейка была хорошая. Может, и её стоит перевести?
Пожалуйста, не учите новичков использовать обычные PHP-шаблоны =( Потом XSS на каждом шагу бывает от такого.
Ну, согласитесь, что в учебных целях вполне можно и про PHP-шаблоны рассказать, а уже потом пояснить, почему оно плохо, и почему нужно учить еще и Jinja-синтаксис из Твига.
В этом и соль, показать на реальном примере разницу. В пхп-шаблоне в симфони для простого вывода переменной вам надо будет в ручную вызвать экранирование:
В твиге в симфони все наоборот: экранирование идет по дефолту, и вам надо использовать фильтр raw чтобы отменить это автоматическое экранирование.
<?php echo $view->escape($name); ?>В твиге в симфони все наоборот: экранирование идет по дефолту, и вам надо использовать фильтр raw чтобы отменить это автоматическое экранирование.
Sign up to leave a comment.
Избавьтесь от аннотаций в своих контроллерах!