Движок блога на Yii. Front и back разделение.

Предыдущие серии

1 Вступление

2 Yii, создаем свою CMS. База данных

Наверное в каждом веб-приложении возникает задача разделения, так называемой клиентской или public части — та часть веб-сайта или веб-приложения с которой работает пользователь и админ или back части —  часть сайта, с которой работают администраторы, контент-менеджеры и прочие пользователи, отвечающие за наполнение сайта. Сегодня я хочу поговорить о том как это сделать, при использовании фреймворка Yii и какой способ выбрал я при разработке Юпи!.

Критериями для выбора способа будут являться следующие:

  • простота реализации
  • необходимость выполнять дополнительные «тело движения» (править .htaccess, колдовать с роутингом и т.д.)

И так…

При использовании Yii можно поступить несколькими способами:

  1. Создать контроллер Admin или Back и всю логику админки реализовывать там;
  2. В каталоге Controllers создать подкаталог admin или back и все контроллеры и экшены для админки располагать там;
  3. Админка в виде отдельного модуля Yii;
  4. Создать два приложения — одно  для админской части, другое для клиентской;

Все четыре способа упорядочены по сложности их реализации и по необходимости выполнять дополнительные действия — т.е. писать код!

Кратко рассмотрим достоинства и недостатки каждого из них.

1  Создать контроллер Admin или Back и всю логику админки реализовывать там — наверное самый простой способ.

Достоинтва:

  • простота реализации;
  • модели используются всем приложением;

Недостатки:

  • если админка будет очень большая (с большим функционалом), наш контроллер «раздуется» до огромных размеров, что затруднит сопровождение проекта (эту проблему, отчасти может решить вынесение экшенов в отдельные классы);
  • нет отделения админки от остальных частей проекта;

2 В каталоге Controllers создать подкаталог admin или back и все контроллеры и экшены для админки располагать там — второй по сложности реализации способ, забегая вперед, скажу, что я выбрал именно его.

Достоинства:

  • админка физически (на уровне каталога файловой системы) отделена от остальных частей проекта, причем это отделение касается не только каталога Controllers, но и каталога View;
  • модели используются всем приложением;

Недостатки:

я пока их не нашел 🙂

3 Админка в виде отдельного модуля Yii — по правде говоря, кода я начал разрабатывать Юпи! и столкнулся с проблемой разделения на back и front части — тогда еще не было поддержки модулей в Yii (она появилась в версии 1.0.3), поэтому данный способ я не рассматривал. Если кто-то пытался поступить таким образом — прошу рассказать о своем опыте в комментариях.

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

Достоинства они же, от части, являются и недостатками:

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

Для себя я выбрал способ №2, он, как мне кажется, наиболее удовлетворяет всем моим требованиям.

Таким образом мы имеем следующую структуру проекта.

Вопрос разделения приложения на 2 части поднимался на официальном форуме Yii, почитать можно тут.

Кроме такого вот разделения приложения на две части, для каждой из них я сделал свой базовый контроллер, таким образом все контроллеры клиентской части наследуются от YFrontMainController, а контроллеры админской части от YBackMainController. Введение новых базовых контроллеров позволяет:

  • реализовать  функционал, специфичный для каждой части приложения, в одном месте, что облегчает повторное использование и сопровождение;
  • как правило, для клиентской и адмиской частей используются разные лайауты (layouts), разделение контроллеров позволяет реализовать это очень просто (для этого достаточно переопределить свойство layout);

Например, для всех контроллеров админки, я применяю фильтр, проверяющий авторизацию пользователя, не имея базового контроллера, мне бы пришлось прописывать его во всех контроллерах админки. Так же применяется xss-фильтр, для всех данных, отправляемых из панели администрирования.

Скорее всего,  выбранное мной решение, не является идеальным и имеет скрытые (пока!) от меня недостатки, если Вы о таковых знаете — прошу высказываться в комментариях.

Удачного yii-кодинга, друзья!

Обсудить на форуме

Основной сайт Юпи! — http://yupe.ru

Исходный код — https://github.com/yupe/yupe

Присоединяйтесь!

Читайте еще:

  • Думаю вариант 3

    Давно пора сразу думать о более гибкой архитектуре — SaaS!
    Купили сайт, делать ничего не хотят, админка удалённая, просто подконектился и управляешь(за саппорт гребёшь бабло), а все контролери и вьюхи екстендятся издалека (могут например загружатся тарчиком во временную директори, на момент работы), или из модуля…

    На самом сайте только то, что нужно для его работы, не более!
    ps: тут много тем для разговора можно поднять 😉

  • xoma

    Конечно такой вариант возможен! Но, по моему мнению, он подходит для «больших» и «Масштабных» CMS-ок, а для блога — это будет излишеством (если конечно не планируется создавать 10-15 блогов и управлять ими из одной панели) ИМХО конечно!

  • Так ты блог создаеш или CMS? чета непонятно =)

  • xoma

    Вообще блог! Но может все перерастет в простенькую ЦМС-ку )))

  • Я пробовал отдельное приложение. На самом деле, все не так страшно как вы пишете 🙂 Копируется конфиг фронтенда (фактически, нужен только доступ к базе и настройки юзера + что сами используете), если используете перезапись урлов — то правите хтаксес и наслаждаетесь — все модели, контроллеры и т.п. доступны, потому что новое приложение — это всего лишь новая точка входа. Я описывал вот здесь как сделать: http://www.yiiframework.com/forum/index.php/topic,924.msg12171.html#msg12171

  • Вот нашёл тут CMS-ку со схожем названием:
    http://yupi-cms.com/

  • Вот блин….просмотрел…может придумать другое название или все-таки оставить??

    Yupe! != Yupi !!!

  • Думаю можно попробывать придумать другое.
    А лучше — выставить это на голосование.