Структура каталогов для MVC - PullRequest
15 голосов
/ 01 ноября 2011

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

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

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

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

Ответы [ 4 ]

18 голосов
/ 01 ноября 2011

Я бы предложил вам изучить структуру каталогов фреймворка, например, 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 для выражений, YourView.phtml для представлений и т. Д. Проверьте структуру, и вы узнаете, как правильно структурировать и использовать приложение.

8 голосов
/ 01 ноября 2011

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

Отрывок из книги "Полное руководство по Symfony" Фабьена Потенсье и Франсуа Занинотто:

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).
  • log / Хранит соответствующие файлы журналов, сгенерированные непосредственно Symfony. Может также содержать файлы журнала веб-сервера, файлы журнала базы данных или файлы журнала из любой части проекта. Symfony создает один файл журнала для каждого приложения и среды (файлы журнала обсуждается в главе 16).
  • plugins / Хранит плагины, установленные в приложении (плагины обсуждаются в главе 17).
  • test / Содержит модульные и функциональные тесты, написанные на PHP и совместимые с среда тестирования Symfony (обсуждается в главе 15). Во время настройки проекта, Symfony автоматически добавляет некоторые заглушки с несколькими базовыми тестами.
  • web / Корень веб-сервера. Единственные файлы, доступные из Интернета, это те, которые находятся в этом каталоге.
6 голосов
/ 01 ноября 2011

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

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

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

3 голосов
/ 06 октября 2013
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...