Это вопрос, с которым рано или поздно сталкиваются все, кто использует Yii. Отсутствие явного готового решения в стандартной сборке, отсутствие какой-либо информации в руководстве при одновременном потоке авторских решений в wiki Yii framework, полностью перекладывает задачу разделения backend и frontend на плечи разработчика, где каждый может стать сам себе злым буратино.

Здесь представлен сокращенный вариант статьи из-за ограничений cms livestreet на количество символов в публикации

Задача организации backend/frontend будет также актуальной и для многих других фреймворков, чья архитектура так или иначе похожа на Yii. Кстати рассматриваемая версия Yii framework не принципиальна, но большая часть приводимых мной примеров в данной статье будет актуальна для Yii 1.1.

Общее видение

Если говорить вцелом, то существует два способа разделения backend/frontend, в зависимости от количества точек входа, или другими словами от количества приложений, где с одной стороны разделение происходит внутри одного приложения, а с другой реализация представлена в виде нескольких приложений.

При создании собственной реализации или выборе готового решения рекомендую учесть одновременно несколько моментов:

• Степень связности backend и frontend. Она не только отразится на архитектуре твоего проекта, но и на том, как будет расти код, откуда также станет видно насколько дорого тебе обойдется поддержка и развитие проекта в будущем, ведь любая ошибка в проектирование возрастет впоследствии в несколько раз.
• Трудность реализации. Проблема вытекающая из первой. Если имеет место ограничения по времени, или скажем ты не уверен, что хорошо разобрался с фреймворком, чтобы грамотно собрать свой проект, то лучше заручится уже существующими реализациями.
• Масштаб проекта. Громадная архитектура — громадному проекту, тут все логично и просто. Не следует использовать монстрообразные сборки для реализации своего приложения, как например блога или несложного сервиса для хранения изображений.
• Веб-сервер. Реализация должны быть такой, чтобы при смене хостинг площадки, количество манипуляций с настройками сервера было минимальным.

Разделение backend/frontend в Yii

Что касается Yii framework, здесь могу выделить следующие способы разделения, которые мне довелось встретить и реализовывать в какой-то мере:

• Backend и frontend — два приложения:
  • Разделение на уровне end'ов;
  • Одно приложение вложено в другое;
  • Создание backend/frontend на основе поведений (behaviors).

• Backend и frontend — одно приложение:
  
  • Создание backend и frontend контроллеров;
  • Создание backend в виде модуля.

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

Итак, давай по порядку.

Backend и frontend — как два приложения

Разделение на два приложение — это наверно первое, что могло придти тебе в голову. Идея довольно-таки простая на первый взгляд, каждое приложение содержит в себе свои файлы, а пересекающиеся части выносятся в отдельную общую (common) директорию. На практике приходилось встречаться с двумя вариациями разделения, где в первом случае проект выполнен в виде нескольких приложений (end'ов), а во втором одно приложение вложено в другое. Оба варианта отличаются простой реализацией. Также после краткого изучения поведений (behaviors) в Yii к этим двум способам разделения backend/frontend в твоем наборе решений добавить еще одна реализация.

Разделение на уровне end'ов

В wiki-статье The directory structure of the Yii project site от Qiang (одного из core-разработчиков), показывается пример, подобного разделения на несколько приложений (end'ов), структура директорий выглядит следующим образом:

backend/
    common/
        components/
        config/
            params.php
            params-local.php *
        lib/
            Pear/
            yii/
            Zend/
        migrations/
        models/
            Comment.php
            Extension.php
            ...
    console/
        commands/
            SitemapCommand.php
            ...
        config/
            main.php
            main-local.php *
            params.php
            params-local.php *
        runtime/
        yiic.php *
    frontend/
        components/
        config/
            main.php
            main-local.php *
            params.php
            params-local.php *
        controllers/
            SiteController.php
            ...
        lib/
        models/ 
            ContactForm.php
            SearchForm.php      
        runtime/
        views/
            layouts/
            site/
        www/
            assets/
            css/
            js/
            index.php *
    yiic
    yiic.bat

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

Одно приложение вложено в другое

Organize directories for applications with front-end and back-end, предлагает следующее расположение директорий:

wwwroot/
    index.php
    backend.php
    assets/
    images/
    js/
    protected/
        config/
            main.php
        components/
        controllers/
        models/
        views/
        runtime/
        backend/
            config/
                main.php
            components/
            controllers/
            models/
            views/
            runtime/

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

Backend и frontend на основе поведений

Organize directories for applications with front-end and back-end using WebApplicationEnd behavior, идея заключается в расширение CWebApplication дополнительным методом через поведение, которое в свою очередь определяет новые пути для папкок с контроллерами и представлениями в зависимости от имени end'а.

В результате выполнения инструкций приводимых в wiki-статье структура директорий будет выглядеть так:

webroot/
    index.php
    backend.php
    protected/
        components/
            Controller.php
            UserIdentity.php
        controllers/
            /front
                SiteController.php
            /back
                SiteController.php
        views/
            /front
                /layouts
                    column1.php
                    column2.php
                    main.php
                /site
                   /pages
                       about.php
                   contact.php
                   error.php
                   index.php
                   login.php
            /back
                /layouts
                    main.php
                /site
                    error.php
                    index.php
                    login.php

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

Общие моменты при использовании нескольких приложений

Несколько приложений — несколько точек входа, здесь всем вышеуказанным реализациям свойственно:

• Авторизация пользователя. Авторизация распространяется только на один end', авторизовавшись в одном приложении, вы будете по прежнему гостем в другом;
• Марштрутизация. Чтобы сделать красивый URL для backend.php придется несколько поиграть с .htaccess и/или правилами в UrlManager или придумать что-то другое;
• Модульность. В случае с поведениями происходит отказ от использования стандартных модулей.
• Слабая связь между end'ами. Нужно помнить, что каждого end' свои файлы: ресурсы, компоненты, модули и т.п, а если и есть общая часть то скорее она вынесена, чтобы не происходило дублирования, функционально она не создает какой-то зависимости между end'ами, и хотя в большинстве такой задачи не возникает, но тем не менее нельзя сделать ссылку из backend во frontend (и наоборот), тебе придется что-нибудь придумать на этот счет.

Backend и frontend — одно приложение

Одно приложение, одна связка файлов конфигураций, одна точка входа. В рамках одного приложения backend и frontend Минус один — это лишь модуль приложения, и придётся мириться с тем, что все assets, runtime, css, images и прочее нужно либо делить с «родителем», либо прилагать какие-то усилия, что отделить их от front'а.

Backend и frontend контроллеры

Создаем backend и frontend контроллеры, в которых определяем собственные layouts и правила доступа. Такая реализация подойдет для относительно небольших проектов, поскольку при увеличение числа контроллеров появятся сложности в поддержке проекта.

Структура директорий будет выглядеть так:

webroot/
    protected/
        components/
            ControllerBackend.php
            ControllerFrontend.php
            UserIdentity.php
        controllers/
            BackendSiteController.php
            SiteController.php
        models/
        views/
            /layouts
                column1.php
                column2.php
                main.php
            /site
                /pages
                   about.php
                contact.php
                error.php
                index.php
                login.php

Такая организация уместна в большинстве для малых проектов.

Backend в виде модуля

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

webroot/
    protected/
        components/
            Controller.php
            UserIdentity.php
        controllers/
            SiteController.php
        models/
        modules/
            admin/
                components/
                    ControllerBackend.php
                controllers/
                    SiteController.php
                views/
                    layouts/
                    default/
        views/
            /layouts
                column1.php
                column2.php
                main.php
            /site
                /pages
                   about.php
                contact.php
                error.php
                index.php
                login.php

Реализации backend в смежных модулях в существующих реализациях

Следующим эволюционным шагом в сторону развития backend в виде модуля является создание других модулей с собствеенными backend'ами, которые бы удачно вписывались в разработанную структуру. Рассмотрим вкратце пару рабочих сборок, как они реализуют в себе такое разделение.

Open Real Estate

Сборка от студии Monoray. Бесплатное программное обеспечение для создания сайта агентства недвижимости, разработанное на Yii CMF.

Модуль в момент выполнени

<code>init()</code>

импортирует файлы компонентов и моделей. Также в составе модуля присутствуют хелперы (helpers), но импортируемые вручную. Для реализации backend/frontend контроллеров создано два класса, находящихся в компонентах — Controller и ModuleAdminController, устанавливающие свои права доступа, layouts, некоторые вспомогательные методы. Структура модуля выглядит следующим образом:

\modules
    \apartments
        \components
        \controllers
            \backend
                \MainController.php
            \MainController.php
        \helpers
        \models
        \views
             \backend
        \ApartmentsModule.php

Для запуска backend-контроллеров в правилах машрутизации установлено:

'/backend//' => '/backend//',

Yupe

CMS Yupe содержит основной модуль для управления backend, который включает в себя компоненты, простой фильтр доступа, расширения, хелперы, виджеты и самое главное backend и frontend контроллеры для смежных (дополнительных) модулей.

Структура дополнительного модуля:

\modules
    \catalog
        \controllers
            \CatalogController.php
            \DefaultController.php
        \models
        \views
             \default
        \CatalogModule.php

Дополнительный модуль в основном классе содержит настройки. Что касается контроллеров, то как ни странно в вышеприведенном примере DefaultController.php является backend-контроллером, а CatalogController.php frontend-контроллером.

Замечания при использовании одного приложения

Вся работа происходит в одном приложение и этим уже многое сказано. Тем более такой подход даст тебе несколько больше свободы в развитии проекта, в том смысле, что ты сможешь наращивать проект как модулями, основанными на твоих компонентах, или стандартными модулями Yii. Если тебе необходимо через frontend-интерфейс, скажем, удалять последние комментарии, но при этом авторизация доступна только в backend, то выбор в сторону одного приложения на лицо.

Итог

Как видишь есть несколько общих подходов в решение данного вопроса, не говоря уже о частных вариантах. При этом невозможно определить алгоритм (или блок-схему) для выбора реализации, поскольку все упирается в требования к проекту, к тому в какую сторону и как он собирается развиваться, и помимо этого необходимо решить вопрос связности внутри проекта.

Поэтому Yii framework предоставляет тебе свободу в данном выборе.

Несокращенный оригинал статьи: Организация backend и frontend в Yii framework