Структура проекта для PHP

Ответ 1

Неа. PHP - это то, что вы делаете. Это могут быть очень простые плоские файлы, или же вы хотите его.

При этом существует несколько согласованных стандартов кодирования, но нет "соблюдения" указанных стандартов. Они называются PSR (Рекомендация стандартов PHP). Здесь есть предыстория: http://net.tutsplus.com/tutorials/php/psr-huh/
Вы можете просматривать стандарты по одному здесь: http://www.php-fig.org/psr/

Большинство основных фреймворков следуют этим стандартам, и если вы собираетесь использовать их, может быть проще перейти с потоком.

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

-framework_dir
-public_html
    -js
    -img
    -css
    -index.php
    -protected/private
        -controllers
        -models
        -views
        -etc

Затем они используют файл .htaccess для блокировки доступа к защищенным каталогам. Опять же, это просто общее представление, которое я видел в нескольких рамках. Если вы делаете личный проект, просто используйте то, что вам удобно. Каждая инфраструктура собирается предоставить вам другую библиотеку или способ доступа к данным. Нет "слоев", но опять же каждая структура имеет объекты, которые обрабатывают разные области (электронная почта, база данных, кеш, http, журналы и т.д.). Потому что есть десятки популярных, вам просто нужно найти то, что соответствует вашей философии или проекту. Посмотрите несколько из 5-минутных видеороликов блога, посмотрите, какие дживы, а затем дайте ему пробный прогон на пару дней. Если вам это не нравится, переключитесь на другой.

Ответ 2

К сожалению (или нет?), вы очень свободны с PHP. Это вам.

Здесь моя структура:

framework/
controllers/             
models/
configs/
files/
templates/
themes/
tmp/
index.php
init.php
.htaccess

Вы можете управлять доступом через .htaccess.

Ответ 3

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

В результате получится следующее: https://github.com/php-pds/skeleton

Короче:

If a package has a root-level directory for ...
                            ... then it MUST be named:
command-line executables    bin/
configuration files         config/
documentation files         docs/
web server files            public/
other resource files        resources/
PHP source code             src/
test code                   tests/

Этот стандарт не дает никаких дополнительных рекомендаций относительно того, какие каталоги должны существовать ниже src или public. Я бы предложил просто иметь одно пространство имен ниже src и реализовать любую диверсификацию "моделей", "контроллеров" и т.д., Выполнив это через полное имя класса, например. если принято решение иметь класс Projectname\Controller\WhateverController, он будет находиться на пути, совместимом с PSR-4 src/Controller/WhateverController.php, и будет автоматически загружен через Composer с "autoload":{"psr-4":{"Projectname\\": "src"}}.

Ответ 4

Я предпочитаю использовать структуру папок Feature на основе моих серверных проектов. Каждая папка-функция имеет свой собственный контроллер, менеджер и файл маршрутов. Это хорошо работает для API -backends. Это выглядит примерно так: https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/

Например, у нас есть функция Customer с CustomerController, CustomerRepository, CustomerRoutes,..

Моя структура папок выглядит так:

- build/
-- phpdox.xml
-- phpmd.xml
-- phpunit.dist.xml
- config/
- public/
-- .htaccess
-- index.php
-- assets/
- src/
-- Customer/
--- CustomerController.php
--- CustomerRepository.php
--- Customer.php
--- customer.routes.php
- tests/
- vendor/
composer.json
.gitignore

Ответ 5

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

PROJECT ROOT
|--composer.json
|--README.md
|--docs //for documentation files
|--tests //for Unit Tests
|--vendor //for external libraries (if everything isn't included through composer)
|--examples //examples of the library being used
|--config //any configuration files you may have
|--src  //where the library actual code "lives"
   |--php //php source code, classes, any other scripts
   |--View //html views, but actually php files that output html
   |--Style //contains .css files
   |--Script //contains .js files
   |--Res   //contains other deliverable resource files. Could be mp3 files, json etc

В настоящее время я использую только composer.json, README.md и src среди корневых файлов. Но я, вероятно, буду использовать другие, как я описал, когда я доберусь до этого момента.

Я ни в коем случае не считаю это "правильным". И эта настройка работает только потому, что у меня есть php роутер на каждый запрос. С помощью .htaccess вы можете /src/Style/requested_file.css файл .css в /src/Style/requested_file.css.

Я хотел, чтобы корень проекта был очищен, и я достиг этого. PHP рис не имеет PSR для структур каталогов... что я знаю. Я надеялся, что у PSR-4 у автозагрузчика были бы какие-то стандарты, но... не совсем, в отношении структуры каталогов.

Вы можете посмотреть на laravel, wordpress, PHP Mailer и другие библиотеки php, чтобы увидеть примеры и увидеть, что вам больше всего нравится

Ответ 6

это лучшая структура папок: