Как стать автором
Обновить

Комментарии 11

никогда не понимал зачем вообще нужны отдельные классы-экшены… По сути это часть контроллера. В статье вы говорите о том, что они помогают избежать дублирования кода. Но дублирование кода в контроллерах это нормально (если мы говорим про тонкие контроллеры). Более того, я уже не раз сталкивался с проблемами после таких способов «уменьшить дублирование кода». Особенно это бьет по проектам, которые год нежали себе спокойно и вдруг пришел огромный список чейнджреквестов, при которых все это приходится рассовывать по разным экшенам. Для реюзания кода есть сервисный слой.

Пример с капчей в качестве независимого экшена я так же считаю не совсем корректным. Всегда это напрягало. Это элемент формы, и ему там самое место (к слову почему никто не использует форм билдер?).

По поводу выборок и разделения ответственности — для этого есть сервисный слой. В случае с yii я обычно реализую доступ к базе через статические методы, возвращающие датапровайдер. Причем каждую выборку в отдельный метод. Зачем? опять же удобно в последствии поддерживать и расширять.

Ну и последнее…
protected $_filterModel;

к чему вообще эти пережитки php4?
Отдельных классы action-ов выполняют не столько задачу по укорачиванию кода, сколько по унификации реализации функционала, используемого в разных частях приложения. По тонким контроллерам — поддерживаю, вся логика реализуется именно в моделях. Action реализует лишь связь между запросом и ответом, как бы это не было очевидно. Если есть множество контроллеров, с типичными в общих чертах реализациями action-ов, я думаю вполне обоснованно их реализовать в виде отдельных классов. Расширяемость класса может решить проблему частных случаев. Если же реализовать определенный функционал в контексте класса action-a не получается, его можно и не использовать.

Action каптчи, как и action обработки ошибки в основном подключаются в одном единственном контроллере на всё приложение. Для виджета каптчи можно указать адрес обработчика каптчи. В данной статье они приведены как пример механизма standalone action.

Форм билдер не использует скорее из-за его неочевидности.

По нижнему подчёркиванию у защищённых свойств классов, да, каюсь, давняя привычка обозначать таким образом видимость свойства.
так и не понял в чем отличие от Yii 1.x, кроме использования namespace
так же делаю в 1/x — большинство контроллеров у меня только из списка стандартных actions состоит.
В данном коде особо ничем, но если более внимательно следить за развитием ветки Yii2 — различий достаточно.
Переход на namespace одно из наиболее важных; изменение в ORM (отказ от JOIN'ов); наконец, Twitter Bootstrap с коробки.
и более двух лет разработки…
JOIN'ы вернули на неделе
А какова причина? Падение производительности?
честно говоря, не вникал. Думаю, по просьбам трудящихся.
Речь шла об акшенах — и тут изменений в приведенном примере не видно.
Джойны вернулись, кстати — rmcreative.ru/blog/post/yii2-join-vernulsja
Согласен, данные приемы с action существовали и раньше.
А вот на счет нового поведения с Join — отличное решение.
Появился выбор — делать join или создавать сторонний запрос.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий