Структура каталогов для MVC

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

Models
Views
Controllers
Helpers (Miscellaneous functions)
Libraries (Universal classes, like library and session management)
Images
Style

При вызове страницы маршрутизатор script просматривает связанный контроллер, поэтому thesite.com/login будет создавать экземпляр Login_Controller в '/controllers/login.php'. Проблема, с которой я столкнулся, - это маршрутизатор script сам по себе похож на тип контроллера, как и view.php, который обрабатывает данные форматирования, обрабатываемые соответствующим представлением. Но они не совсем похожи на контроллеры страниц, поскольку они управляют самим MVC. Я до сих пор несколько новичок в этой архитектуре, и мне любопытно, как кто-то с большим опытом организует это.

Могу ли я классифицировать контроллеры маршрутизатора и представления как библиотеки, или было бы лучше создать подкаталог внутри/контроллеров, называемый "страницами", или любые другие идеи? Спасибо.

ОТВЕТЫ

Ответ 1

Я предлагаю следовать структуре Symfony 1.x. Ясный, логичный, безопасный.

Отрывок из книги "Окончательное руководство по Symfony" от Fabien Potencier и François Zaninotto:

apps/
  frontend/
  backend/
cache/
config/
data/
  sql/
doc/
lib/
  model/
log/
plugins/
test/
  bootstrap/
  unit/
  functional/
web/
  css/
  images/
  js/
  uploads/
  • apps/ Содержит один каталог для каждого приложения проекта (обычно, интерфейс и бэкэнд для переднего и заднего офиса).
  • cache/ Содержит кешированную версию конфигурации и (если вы ее активируете) кеш-версию действий и шаблонов проекта. Механизм кэширования (подробная информация в главе 12) использует эти файлы, чтобы ускорить ответ на веб-запросы. Каждое приложение будет иметь подкаталог здесь, содержащий предварительно обработанный PHP и HTML файлы.
  • config/ Сохраняет общую конфигурацию проекта.
  • data/ Здесь вы можете хранить файлы данных проекта, такие как схема базы данных, SQL файл, который создает таблицы или даже файл базы данных SQLite.
  • doc/ Сохраняет документацию по проекту, включая ваши собственные документы и документация, сгенерированная PHPdoc.
  • lib/ Посвящается иностранным классам или библиотекам. Здесь вы можете добавить код, который вам нужен для совместного использования между вашими приложениями. В подкаталоге model/ объектная модель проекта (описанная в главе 8).
    • журнал / Сохраняет файлы журналов, создаваемые непосредственно symfony. Он также может содержать файлы журналов веб-сервера, файлы журналов базы данных или файлы журналов из любой части проекта. Symfony создает один файл журнала для каждого приложения и для среды (файлы журналов обсуждается в главе 16).
  • плагины / Сохраняет подключаемые модули, установленные в приложении (плагины обсуждаются в главе 17).
  • test/ Содержит функциональные и функциональные тесты, написанные на PHP, и совместимые с Symfony (см. главу 15). Во время настройки проекта, Symfony автоматически добавляет некоторые заглушки с несколькими базовыми тестами.
  • web/ Корень для веб-сервера. Единственными доступными из Интернета файлами являются которые находятся в этом каталоге.

Ответ 2

Я бы предложил вам изучить структуру каталога фреймов, например symfony2 или yii

вот что я выбрал для себя:

public_html/              (for public files) (should be public, place only index.php in here)
public_html/css/
public_html/images
public_html/js            (for your js files, or custom generated ones)
lib/                      (for my libs)  (should be private)
lib/vendor/               (for 3rd party libs)
application/              (for the whole app) (should be private)
application/class         (classes that make the app work such as mainApp, Controller, Model, View, etc...)
application/class/model   (all the models)
application/class/view    (all the views)
application/class/view/html (templates used by the views)
application/class/controller (all controllers)
application/class/helper  (helper functions)
application/class/lib     (libs that you develop for the application)
application/template      (layout and/or templates for the application)
application/conf          (config files)
application/log           (log files)
application/cron          (scheduled jobs)
application/database      (for database migration scripts)
...

Вы также можете использовать соглашения об именах файлов, такие как: YourClassName.class.php для clases, YourView.phtml для ваших просмотров и т.д. Проверьте структуру, и вы узнаете, как красиво структурировать и приложение.

Ответ 3

Я бы не назвал себя экспертом, но одно решение заключалось бы в том, чтобы отодвинуть "рамки" от реализации. Я имею в виду переместить ваш "роутер", "view.php" и другие классы инфраструктуры в какое-то внешнее местоположение, которое вы затем включаете в свой index.php или любой другой файл, который будет вашей точкой доступа.

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

Просто идея:)