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

Ответ 1

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

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

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

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

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

Ответ 2

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

project/
 web/
  index.php
  css/
  js/
  images/
 config/
 lib/

• web/- это корень, показанный посетителям.
• lib/находится здесь папка библиотеки и где autoload ищет файлы.

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

EDIT:

Если вы используете композитор (который я рекомендую) и, возможно, 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)

Сделайте развертывание script. Что-то вроде этого:

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

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

Ответ 3

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

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

Для javascripts: approot/скрипты/

Для CSS: approot/стили/

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

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

Для кэшей: approot/кэша/

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

Файл всех страниц: approot/

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

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

Ответ 4

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

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

Ответ 5

Я использую 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 framework.

Здесь "codeIgniter" - это соответствующий

Ответ 6

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

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

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

EDIT:

Это также упоминается в PHP The Right Way в разделе Структура общего каталога.

Ответ 7

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

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, ... */

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

Несмотря на то, что этот вопрос давно устарел, я все же считаю целесообразным предложить последнюю масштабируемую структуру приложения, с которой я работал в своем приложении на основе SOA и работает абсолютно нормально.

myApplication/

    app/
        config/ 
        +         this can include custom MVC structure
    cli/ 
    docker/
    lib/        - most commonly reusable components
    logs/
    public/     - should contain all publicly exposable web contains
    sql/        - db migration stuffs
    tests/      - compulsory test
    tools/      - application addon tools like any kinds of rulset etc
    vendor/