Intereting Posts

Какова наиболее масштабируемая структура каталогов на основе PHP для большого сайта?

Я создаю очень большой сайт на основе MVC на базе MVC, который будет иметь большую библиотеку php-классов, javascripts и многие файлы css (не говоря уже о большом количестве файлов для MVC).

Впервые я на самом деле трачу время на планирование чистой и организованной структуры каталогов.

Какими структурами каталогов вы обычно пользуетесь, и что будет проще для manuever, когда есть тысячи файлов?

Это моя настройка. Это отлично подойдет для меня для небольших – очень больших проектов (в том числе и для социальной сети).
Эти папки будут жить в моей основной папке приложения:

  • config – содержит настраиваемые файлы конфигурации PHP
  • css – содержит файлы CSS проекта
  • helpers – содержит «вспомогательные» файлы (каждый файл представляет собой набор функций)
  • изображения – содержит изображения проекта
  • js – содержит файлы Javascript проекта
  • lib – содержит классы PHP, специфичные для проекта
  • модули – My MVC framework позволяет упаковывать разделы сайта в виде модулей
    • blog – примерный модуль
      • контроллеры – содержит контроллеры для модуля
      • модели – содержит модели для модуля
      • views – содержит представления для модуля
  • views – содержит представления, которые должны быть доступны по всему миру (заголовок страницы, нижний колонтитул и т. д.).

Все каталоги, очевидно, могли содержать подпапки, которые могли бы упорядочить ваши файлы. Например, папка «css» может иметь подпапки с именем «web» и «mobile». Папка «images» может содержать папку «user_uploaded», которая затем может содержать «профайл». И, конечно, вы можете добавлять папки по своему усмотрению, в одном проекте у меня есть папка под названием «uploaders», которая просто содержит автономные сценарии загрузки.

Я также использую удобные методы, которые помогают создавать имена файлов, которые я хочу загрузить. Например, мой loadView () будет искать файл вида в текущем каталоге модуля, или если вы передадите необязательный аргумент $ module, он будет выглядеть конкретно в папке этого модуля.

Надеюсь, это поможет.

У вас должен быть один каталог в качестве веб-корня, где должны находиться только файлы, которые вы хотите открыть для всего Интернета.

 project/ web/ index.php css/ js/ images/ config/ lib/ 
  • web / – это корень, показанный посетителям
  • lib / здесь находится папка библиотеки и где autoload ищет файлы.

Вы можете добавить дополнительные подпапки для проекта / типа контроллера, модулей, представления, помощника и т. Д. Это зависит от вашей структуры.

РЕДАКТИРОВАТЬ:

Если вы используете композитор (который я рекомендую) и, возможно, npm с grunt и меньше ваша файловая структура будет выглядеть следующим образом:

 project/ web/ js/ css/ images/ index.php cli/ config/ config.php node_modules/ src/ test/ vendor/ composer.json composer.lock packages.json 
  • web / имеет все ваши общедоступные файлы
  • cli / скрипты и программы, запускаемые из командной строки NOT web
  • config / имеет все ваши файлы конфигурации (в git вы игнорируете config.php и вместо этого имеете config.dist.php без имен пользователей, паролей, кодов подтверждения и префиксов таблиц / суффиксов и других «секретов»)
  • node_modules / имеет все ваши файлы библиотеки из npm (в git я предлагаю вам поместить это в подмодуль)
  • src имеет все ваши локальные PHP-файлы в структуре psr4, настроенные на автозагрузку в composer.json
  • test / имеет все ваши модульные тесты для ваших классов src, настроенных в autload-dev в composer.json (не забудьте использовать установку композитора –no-dev на live, возможно, добавьте -o, если у вас не слишком много классов)
  • у продавца есть все ваши файлы библиотеки из композитора, а ONE AND ONLY autoload.php для включения в web / index.php и любые скрипты cli (в git я предлагаю вам игнорировать эту папку поставщика)

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

Для развертывания используйте эту структуру:

 /sites/project/ (project is your projectname) current (alias to current release folder releases/v1.1.0) previous (optional alias to previous release folder releases/v1.0.1) releases/ v1.0.0/ (git checkout of tag v1.0.0) v1.0.1/ (git checkout of tag v1.0.1) v1.1.0/ (git checkout of tag v1.1.0) shared/ (has all your shared files and folders to be aliased in all releases - maybe something like GlusterFS) 

Создайте сценарий развертывания. Что-то вроде этого:

Сначала возьмите резервную копию db или скопируйте ее в новую базу данных, проверите git repo в новую папку с тегом release, получите все подмодули git, запустите компоновщик install –no-dev, настройте любые псевдонимы для общих папок и файлов, таких как загруженные изображения и файлы конфигурации, генерировать js / css с хрюканьем и меньше или эквивалент, указывать текущий псевдоним в новую папку с тегом, запускать сценарий обновления базы данных, перезапускать службы nginx / apache / fpm-php, запускать тесты для проверки веб-сайта.

Попросите сценарий вернуться к предыдущей версии (или руководству, чтобы вы знали, что делать).

Для основных файлов, которые включены: approot / inc /

Для функций доступа и классов доступа к данным относятся: approot / dao /

Для javascripts: approot / scripts /

Для CSS: approot / styles /

Для изображений: approot / img /

Для статического содержимого (обычно для изображений профиля пользователя или загруженных изображений): approot / static /

Для кэшей: соответствие / кеш /

Для шаблонов или Просмотр файлов: approot / templates /

Все файлы страниц: approot /

Структура из Samstyle PHP Framework


Ответ, который я разместил здесь, был с 2009 года. За эти годы были опубликованы новые стандарты, в том числе PSR-0, который охватывает тему о структуре папок. У меня также есть новая (и я чувствую, что это лучше) структуру папок с Packfire Framework .

По моему опыту, вы никогда не планируете этого. Вы можете попытаться следить за тем, какие рамки делают, но я считаю, что я не совсем точно вписываюсь в их форму.

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

Я использую codeigniter для небольших и больших проектов. Это MVC-функция умеренно хороша.

  • codeIgniter \ system \ application \ config: содержат все типы файлов конфигурации, такие как DB, шлюз оплаты, ftp config, маршруты и …
  • codeIgniter \ system \ application \ models: содержат все типы классов баз данных, вы должны создавать подпапки в соответствии с вашими потребностями, я использовал клиентов, mailData, paymentModel, отчет, веб-сервис и ….
  • codeIgniter \ system \ application \ views: содержат все виды файлов, которые будут работать как выходные данные для клиентов, вы должны подумать о повторном использовании этих файлов, если это возможно. Как и модели, вам приходилось создавать подпапку, такую ​​как администрирование, отчеты, электронная почта, email_template …..
  • codeIgniter \ system \ application \ controllers: это самая важная часть. Это поможет создать URL-адрес SEO, поэтому на этот раз вы должны быть более осторожны в подпапках. Вы можете создавать как администрирование, продукты, отчеты, заказы ….. и рассмотреть хорошее имя для функций класса контроллера.

Это были файлы PHP / HTML.

Теперь о других файлах:

  • codeIgniter \ images: для изображений
  • codeIgniter \ scripts: для скриптов Java и их структуры
  • codeIgniter \ styles: для CSS
  • codeIgniter \ uploads: для загруженных файлов, если вы не хотите помещать файлы в БД

Подробные сведения см. В разделе frameworkIgniter.

Здесь «codeIgniter» является подходящим

Посмотрите на структуру symfony 1.4 или symfony 2 . Выберите наиболее интуитивно понятный для вас.

Я считаю, что это зависит от того, насколько большой будет проект. Это то, что я использовал в основном:

проект /
index.php
IMG /
CSS /
JS /
Просмотры/
функции /

Пока все файлы проекта организованы …

Это в основном вопрос предпочтения, быстрый поиск в Google показал бы множество различных структур проекта. Но было бы очень хорошо, если бы был согласованный стандарт. Я думаю, что эта инициатива по стандартам разработки пакетов PHP – хороший кандидат.

Это структура каталогов, которую они предлагают:

  • bin / : исполняемые файлы командной строки
  • config / : файлы конфигурации
  • docs / : файлы документации
  • public / : файлы веб-сервера
  • resources / : другие файлы ресурсов
  • src / : исходный код PHP
  • тесты / : тестовый код

Это структура, которую я использую в настоящее время,

 public/ assets/ /* js, css, imgs, ... */ index.php src/ config/ /* for config files */ helpers/ /* for functions */ libraries/ /* for free classes that are not MVC classes */ models/ /* for M in MVC */ views/ /* for V in MVC */ controllers/ /* for C in MVC */ vendor/ /* for vendors files */ uploads/ /* for uploaded images, docs, ... */