структура проекта Кохана - PullRequest
2 голосов
/ 15 мая 2010

Я исследую использование Kohana для моего следующего проекта. Сайт будет состоять из регистрации пользователей (и, следовательно, профилей пользователей), где пользователи будут иметь определенные привилегии. На сайте также есть раздел администратора, куда администраторы могут перейти, чтобы сказать, заблокировать пользователя или удалить сообщение, или посмотреть статистику использования, например. Хорошим сайтом сравнения будет многопользовательский блог, где каждый блоггер в зависимости от своих прав может публиковать / редактировать / удалять блоги ... просто в качестве примера.

Во-первых, я не уверен в том, как настроить структуру контроллера / представления для того, чтобы отделить административный раздел от фронтального сайта. Я использую Kohana 3, поэтому я думал о структуре контроллера следующим образом: приложение / классы / контроллер / фронт (лицевая сторона) ... и приложение / классы / контроллер / админ (для административного раздела).

Или я заметил, что вы можете использовать класс Route для настройки маршрутов, чтобы я мог настроить маршрут "admin". например: www.example.com/admin приведет к экрану входа администратора. www.example.com ---> Фронт-контроллер.

Кроме того, могу ли я каким-то образом отделить представления и контроллеры "Admin" от представлений и контроллеров "лицевой стороны", например разделить их на основе структуры папок? Любая помощь очень ценится.

Спасибо.

Ответы [ 2 ]

4 голосов
/ 15 мая 2010

У вас может быть отдельная папка приложения для администратора и интерфейса:

  • приложение
    • классы
      • Контроллер
      • модель
    • просмотров
  • admin_application
    • классы
      • модель
    • вид

Этот подход позволит вам индивидуально настраивать каждую среду начальной загрузки и красиво разделять различные файлы. Однако из-за этого разделения вам потребуется структурировать общий код в виде модулей, чтобы обеспечить возможность совместного использования функциональности между двумя приложениями. Конечно, вы можете просто продублировать код, но сейчас это будет неправильно, не так ли? ;)

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

  • приложение
    • классы
      • контроллер
        • админ
      • модель
        • админ
    • просмотры
      • админ

Этот подход делает файлы немного более смешанными и может усложнить их обслуживание (в зависимости от вашей перспективы), но его, безусловно, легче реализовать. Одним из преимуществ этого подхода является то, что вы можете создать папку / public_html / admin и защитить ее с помощью .htaccess (вам также необходимо добавить копию обычного файла index.php). Затем всякий раз, когда поступают запросы http://yourdomain.com/admin, файл .htaccess срабатывает и защищает ваше приложение администратора на уровне веб-сервера. Кроме того, запрос будет автоматически направляться во вложенные папки / admin в различных папках, поэтому вам также нужно меньше работать, когда дело доходит до маршрутизации.

В обеих ситуациях использовались бы (удивительные) механизмы маршрутизации Kohana для обработки того, какие запросы были отправлены куда, и каждый так же безопасен, как и другой, с точки зрения доступа к приложению. Я предположил, что вы используете KO3, кстати ...

EDIT
На самом деле, вы можете защитить .htaccess приложение администратора, если вы используете первый метод тоже. Вам просто нужно адаптировать файл /admin/index.php, чтобы он указывал на приложение администратора.

1 голос
/ 17 мая 2010

Мой подход был бы аналогичен первому, но затем для каждого модуля я бы создал контроллер администратора и контроллер внешнего интерфейса - все мои контроллеры администратора наследовали бы от абстрактного контроллера администратора, который имел бы аутентификацию в методе before - или как то так.

...