Backend в проекте на Yii

[@MrLoki]

По моему для такого подхода неплохо было бы дописать генераторов в Gii.

Насчет Create\Update — да по умолчанию они одинаковы, но тут скорее рассчитано на то, что возможны разные действия при вставке\изменении в контролере, поэтому и разбито на 2 action`а.

Понравилась идея разбить action и controller, ибо действительно получалось много, зачастую одинакового, кода.

Не совсем понял почему именно Backend? Такой подход может быть применен для организации однотипных действий где угодно, и Backend не всегда самый удачный пример для этого, ибо там часто бывает много специфичных действий для работы с записями.

[@sdevalex]

Разные действия для Create\Update зачастую лучше всего описать в beforeSave\afterSave модели. Пример с Backend привел потому, что в момент написания статьи вся голова была забита именно этим, но в любом случая уникальный код пишется большей частью для фронта (может быть и по другому, но пока ещё не сталкивался).

[@MrLoki]

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

Просто после прочтения заголовка, я сразу подумал об очередном холиваре на тему организации бэка для Yii.

[@sdevalex]

По коду… если для какого-либо Action нужна отдельная модель, то можно сделать так:

public function actions()
{
     return Cmap::arrayMerge(parent::actions(), array(
          'list' => array(
               'class' => 'backend.actions.ListAction',
               'modelName' => 'SomeModel',
          ),
     ));
}

[@nayjest]

Вещи типа универсальной корзины думаю, удобнее делать behavior'ами для модели (если хочется универсальности).

Я например использую behavior для хранения автора/даты создания/даты последней правки (кроме добавления геттеров и сеттеров поведение навешивает на модель события beforeSave/afterSave, beforeValidate/afterValidate).

И версионность, с ней по-моему особенно удачно получилось. Поведение (behavior) создает новую таблицу по подобию таблиц owner'а с суфиксом '_revisions', расширяет первичный ключ таблицы колонкой 'revision' и навешивает модели обработчик afterSave, который дополнительно сохраняет запись в таблицу с ревизиями. А также добавляет модели методы для работы с этим всем добром.

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

И еще: да, описанный sdevalex'ом подход вполне имеет право на жизнь, но очень много удобства все-таки добавляет кодогенератор, собственные шаблоны рулят.

p.s.: Оформляйте в виде расширения и выкладывайте на Yii extensions!

[@sdevalex]

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

[@yul]

В условии defaultScope лучше указывать alias:

$alias = $this->getTableAlias(false, false);
return array( 'condition' => "$alias.status=" . self::STATUS_DEFAULT);

иначе при join'е таблиц с одинаковыми полями status будет неоднозначность.

[@KorP]

>2. Создаем базовую модель, которая в умеет случае умеет работать с корзиной.