Структура php проекта: phpstorm — Структура приложения PHP

phpstorm — Структура приложения PHP

Здравствуйте. Хотелось бы попросить совета, как правильно организовать структуру приложения. Я только учусь разработке на PHP. Не судите строго.

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

Не могу представить в голове структуру. На данный момент Вижу только такое:

По папкам:

1. auth — Страница авторизации;
2. profile — Страница с личным кабинетом, куда пользователь попадет после авторизации;
3. templates — header.php,footer.php и остальные файлы, все они будут, как шаблон сайта
4. core — предположительно ядро, и через эту папку можно будет войти в админку;
5. lib — другие функции…

Вот из этого вопрос, как лучше организовать это.

• php
• phpstorm

2

У меня обычно для несложных приложений с нуля структура, позаимствованная из систем пэкиджей Linux и Windows, некоторый микс:

1. В приложении есть модули
2. Каждый модуль хранится в своей папке (это список папок, а не дерево)
3. В этой папке есть подпапки, например, php, css, js, html, tpl
4. Любое обращение, за исключением запросов к файлам (картинкам), производится только к одному скрипту: index. php, в котором настраивается autoload.
5. Чтобы к index.php нельзя было обратиться напрямую, в файле .htaccess с помощью mod_rewrite задается переменная MODULE c соответствующим значением, например, admin или frontend (это названия модулей), которая будет видна в массиве $_SERVER
6. Усли у заданного модуля есть контроллер, хоторый лежит в файле modulename/php/Ctrl.php, то index.php созздает экземпляр этого контроллера и запускает.

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

Смотрите как это организовано в популярных фреймворках. Например:

• https://github.com/yiisoft/yii2-app-basic
• https://github.com/yiisoft/yii2-app-advanced
• https://github.com/zendframework/ZendSkeletonApplication

Да тот же 1С-Битрикс установите — посмотрите структуру как делать не стоит или наоборот стоит (тут на вкус и цвет. ..) 😉

А лучше на основе фреймворка и делать проект. Когда над вашим проектом будут работать другие люди — за самописное решение большого спасибо не скажут.

Именованием файлов, стайлгайд, автолоадер и т.д. обратите внимание на http://www.php-fig.org/psr/.

Если возникнет вопрос: а что изучать? Смотрите и отталкивайтесь от вакансий — что требуется и что чаще, а также вилку ЗП.

И не PHP едины — это главное не забывайте.

5

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

By clicking “Отправить ответ”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

php — laravel apiato структура проекта на два и более api

Вопрос задан 7 месяцев назад

Изменён 7 месяцев назад

Просмотрен 72 раза

Всем привет, в проекте нужно создать два api, однин приватный для своего фронта, а второй публичный, они полностью разные, экшены для публичного апи нельзя использовать а приватном и на оборот. Как правильно в таком проекте сделать структуру, чтоб файлы не переплитались между собой, у также разделить роутинг, к примеру приватный должен быть на www.example.com/api/…, а публичный www.example.com/api/v1/…

Сам проект на laravel apiato

• php
• laravel
• apiato

Да как угодно можно организовать, вплоть до отдельного домена. Мне так кажется удобнее да же. private.example.com/api/v1 и example.com/api/v1.

В роуте Route::domain(...) прописываете и в nginx вторую директорию сервер (ну если локально, то свои домены в свой сервер который используете указываете). Далее вешаете проверку на доступы (middleware) на каждую группу маршрутов и всё.

Если вопрос про контроллеры и прочие обработчики, то используйте модульную систему, для объединения в одну папку (как при проектировании пакета):

Например в app директории будут папки: app/Api/Private и app/Api/Public А внутри каждой будет такая же структура как и в папке

app проекта. Http,Models,Console,Providers и так далее. В результате мы получаем всё что относится к публичному апи в нужной директории и наоборот.

Если оба api используют общие вещи, например request некоторые или ещё какие-либо сервисы, то их выносите в обычные Http,Models,Console,Providers в папке app проекта.

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

By clicking “Отправить ответ”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Каталог

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

спросил 9 лет, 8 месяцев назад

Изменено 1 год, 2 месяца назад

Просмотрено 81к раз

Я новичок в PHP и хочу знать структуру каталогов для проектов php. У меня есть опыт работы с Java, и в java у нас есть src, содержащий исходные файлы java, WEB-INF, содержащий страницы lib и jsp. Есть ли у нас аналогичная стандартная структура каталогов в PHP? Также у нас есть слои в php, как у нас есть слои в java (например, веб-уровни, сервисы, слои DAO)

Я просмотрел несколько ссылок. Но каждый дает разные ответы.

Не уверен, что мы можем сравнить два языка. Я просто хочу придерживаться некоторых стандартов.

Заранее спасибо.

• 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
    -защищенный/частный
        -контроллеры
        -модели
        -Просмотры
        -и т. д
 

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

Посмотрите несколько 5-минутных видеороликов в блоге, посмотрите, что вам нравится, а затем протестируйте их в течение пары дней. Если не нравится, переключитесь на другой.

1

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

Результат такой: https://github.com/php-pds/skeleton

Вкратце:

.

Если пакет имеет корневой каталог для	, то он ДОЛЖЕН называться
исполняемые файлы командной строки	бин/
файлы конфигурации	конфиг/
файлы документации	документов/
файлы веб-сервера	публичный/
другие файлы ресурсов	ресурсов/
Исходный код PHP	ист/
тестовый код	теста/

Этот стандарт не дает никаких дополнительных рекомендаций относительно того, какие каталоги должны существовать ниже источник или общедоступный .

Задача организации ваших исходных файлов PHP внутри любого из этих каталогов по-прежнему зависит от вас, но в этой статье есть предложения, с которыми я согласен: либо сортировать по типу (контроллер, объект, служба), либо сортировать по функциям (пользователь, логин, корзина, каталог, статья, комментарий) — последний хранит весь код, принадлежащий одной функции, в каталоге (или нескольких подкаталогах), что часто кажется лучшей организацией файлов.

При организации по типу вы обнаружите, что довольно часто перескакиваете между каталогами, а также не получаете хорошего представления о том, что представляет собой код — у вас всегда будет «Контроллер», но у вас редко будет «StampCollection».

Я обычно использую структуру папок на основе функций для своих серверных проектов. Каждая папка функций имеет свой собственный контроллер, менеджер и файл маршрутов. Это хорошо работает для 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
- конфиг/
- общественный/
-- .htaccess
-- index.php
-- ресурсы/
- источник/
-- Клиент/
--- КлиентКонтроллер.php
--- CustomerRepository.php
--- Клиент.php
--- клиент.routes.php
- тесты/
- продавец/
композитор.json
.gitignore
 

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

Вот моя структура:

 framework/
контроллеры/
модели/
конфиги/
файлы/
шаблоны/
темы/
температура/
index.php
init.php
.htaccess
 

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

6

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

 КОРЕНЬ ПРОЕКТА
|--composer.json
|--README.md
|--docs //для файлов документации
|--тесты //для модульных тестов
|--vendor //для внешних библиотек (если не все подключается через composer)
|--examples //примеры используемой библиотеки
|--config //любые файлы конфигурации, которые у вас могут быть
|--src //где "живет" фактический код библиотеки
   |--php //исходный код php, классы, любые другие скрипты
   |--Просмотр //html-представлений, но на самом деле php-файлов, которые выводят html
   |--Стиль //содержит файлы . css
   |--Script //содержит файлы .js
   |--Res //содержит другие файлы ресурсов для доставки. Это могут быть файлы mp3, json и т. д.
 

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

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

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

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

1

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Обязательно, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания и подтверждаете, что прочитали и поняли нашу политику конфиденциальности и кодекс поведения.

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

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

 проект/
 веб/
  index.php
  css/
  js/
  изображений/
 конфиг/
 библиотека/
 

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

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

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

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

 проект/
    веб/
        js/
        css/
        изображений/
        index.php
    Кли/
    конфиг/
        config. php
    node_modules/
    источник/
    тест/
    продавец/
    композитор.json
    композитор.lock
    пакеты.json
 

• web/ содержит все ваши общедоступные файлы
• cli/скрипты и программы, которые нужно запускать из командной строки, а НЕ из Интернета
• config/ содержит все ваши файлы конфигурации (в git вы игнорируете config.php и вместо этого имеете config.dist.php без имен пользователей, паролей, кодов проверки, префиксов/суффиксов таблиц и других «секретов»)
• node_modules/ содержит все файлы вашей библиотеки из npm (в git я предлагаю вам поместить это в подмодуль)
• src содержит все ваши локальные файлы PHP в структуре psr4, настроенные на автозагрузку в composer.json
• test/ содержит все ваши модульные тесты для ваших классов src, настроенные в autload-dev в composer.json (не забудьте использовать composer install —no-dev в прямом эфире, возможно, добавьте -o , если вы этого не сделаете слишком много классов)
• поставщик имеет все файлы вашей библиотеки из композитора и ОДИН И ТОЛЬКО autoload. php для включения в web/index.php и любые сценарии cli (в git я предлагаю вам игнорировать эту папку поставщика)

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

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

 /sites/project/ (проект — это имя вашего проекта)
    текущий (псевдоним текущей папки выпуска releases/v1.1.0)
    предыдущий (необязательный псевдоним для папки предыдущего выпуска releases/v1.0.1)
    релизы/
        v1.0.0/ (git checkout тега v1.0.0)
        v1.0.1/ (git checkout тега v1.0.1)
        v1.1.0/ (git checkout тега v1.1.0)
    shared/ (имеет псевдонимы для всех ваших общих файлов и папок во всех выпусках — может быть, что-то вроде GlusterFS)
 

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

Сначала сделайте резервную копию базы данных или скопируйте ее в новую базу данных, извлеките репозиторий git в новую папку с тегом выпуска, получите все подмодули git, запустите composer install —no-dev, настройте любые псевдонимы для общих папок.