Я нахожусь на ранних стадиях создания веб-приложения MVC. Я хочу попробовать и сделать что-то в стиле композитора. Вот моя структура каталогов:
public_html |-vendor | |-MyVendorName | | |-DomainObjectClass.php Так вот где я храню объекты домена.
Я также пытаюсь сделать MVC как можно ближе к тому, как это делается в ответе на этот вопрос
Там, где я немного застрял, нужно поместить модель, контроллер, просмотр, службы, DataMappers и т. Д. Должен ли я делать подкаталоги MyVendorName (например, MyVendoreName / DomainObjects / DomainObjectClass.php и MyVendorName / Services / SomeServiceClass.php и т. Д.), Или это быть разумнее сделать каталог отдельно от поставщиков, называемых классами или src, или что-то еще, и что там делать MVC?
Изменить: все говорят, что поставщик для сторонних библиотек, я понимаю. Но способ, которым я пишу объекты своего домена, очень развязан со стороны MVC. Фактически, они даже не знают, что они являются частью приложения MVC. Их можно было бы легко использовать в других проектах (я намереваюсь это сделать). Поэтому мне кажется нелогичным помещать его в src / or app /
Это чрезвычайно спорная тема, и нет ни одного правильного ответа. Тем не менее, я отказался от следующих советов:
vendor предназначен для сторонних зависимостей, вы не должны писать свой собственный код в нем src или lib , рядом с каталогом vendor MyVendorName\Controller , MyVendorName\Model и т. д. MyVendorName\Model\DomainObjects\Foobar\Subclass насколько это имеет смысл, например MyVendorName\Model\DomainObjects\Foobar\Subclass имеет смысл Я бы предложил такой подход:
project_dir |-vendor | -(vendor directories, installed via composer) |-public_html (images, javascript, css, html files/angular views) |-app
Внутри вашего каталога app вы помещаете свой PHP-код. Внутри там вы можете организовать свои контроллеры, службы, картотеки данных, как вам нравится, но эта структура обеспечивает строгое разделение между тем, что должно быть доступно извне ( public_html ), и что должно выполняться только apache или cli (все остальное).
Однако, как сказал @deceze, помимо того, что вы нарушили каталог поставщика и общедоступный каталог, как вы упорядочиваете свой код приложения, полностью зависит от вас и должен соответствовать тому, что наиболее подходит для задачи, которую вы пытаетесь выполнить.
заявка
Это зависит от вас, как вы хотите структурировать свое приложение. Это хорошая практика, чтобы помещать ваши вещи в папку src или app . MVC – всего лишь вспомогательный метод, обеспечивающий более или менее чистую структуру папок для него. Вы должны прочитать о PSR и пространствах имен, чтобы понять, как назвать ваши классы. Если вы следуете стандартам PSR, вы получаете прямую связь имен папок, имен файлов и имен имен с именами внутри этих файлов.
/src - /controller - ModuleAController.php - ModuleBController.php - /model - /helper - /view - bootstrap.php - config.php - index.php
или
/src - /core - corefiles.php - ... - /modules -/aModule - /controller - /model - /helper - /view - bootstrap.php - config.php - index.php
Композитор
Композитор – менеджер пакетов. Вы можете получить с ним пакеты. Эти пакеты хранятся в папке vendor . Пакеты определяются внутри файла composer.json вашего проекта. Вы можете определить два отдельных раздела require: require , который определяет зависимости для вашего проекта и require-dev , который определяет зависимости, необходимые только для разработки вашего проекта.
Композитор действует также как генератор автозагрузки, для всего проекта (вашего приложения и всех его зависимостей).
{ "autoload": { "psr-4": {"YourApplicationNamespace\\": "src/"} } }
Вам просто нужно потребовать, чтобы файл автозагрузки композиторов из папки поставщиков был загружен в начальной загрузке вашего проекта.
require 'vendor/autoload.php';
Если компоненты являются автономными и многоразовыми, вы можете создать их в виде отдельных пакетов композиторов и потребовать их в своем основном приложении. Например, это будет работать для пакета «logger». Таким образом, некоторые из рамочных проектов составляют свой основной проект.
Пользовательский установщик композитора
Если компоненты связаны с общим базовым уровнем (CMS или Framework), вы можете использовать специальный установщик для компоновщика, чтобы пакеты были установлены в правильную папку. Здесь вы найдете много макетов папок и информации о структуре: http://github.com/composer/installers
project -vendor -(packages installed via composer) -public_html (assets and main index.php) -src - core - helpers (composer packages for this application, installed into specific folders) - themes - sunshine (theme package installed into themes folder) - modules - guestbook (module package installed into modules folder)
Я привел пример ниже, который вам может понравиться. Принимая решение о моей структуре каталогов, я нашел полезную статью здесь: https://softwareengineering.stackexchange.com/a/123320
/app - /controller_http.php - /controller_cron.php /data # content uploaded by users or generated by scripts /lib - /[MyName]/Controller/ - /[MyName]/Myclass.php /test /vendor - /[vendorName]/assets/images/ - /[vendorName]/ClassName.php - /[VendorName]/Module/ /www # or /public_html - index.php - /css - [theme name]/stylesheet.css - [theme name]/images/ # images specific to a theme/stylesheet - /images # general images for any theme - /js .gitignore bootstrap.php composer.json licence.txt README.md
Приложение может запускаться из разных контекстов, например:
HTTP-запрос из браузера: index.php включает controller_http
Cron Job: controller_cron.php вызывается непосредственно
API-вызов: controller_api.php, вызванный из www / api.php
В каждом случае контроллер будет включать bootstrap.php для определения путей каталога и другой жестко кодированной конфигурации. Затем он запускал соответствующие сценарии на основе параметров запроса или аргументов командной строки
Ниже приведен пример приложения MVC, написанного на PHP, и который внимательно следит за принципами MVC:
https://github.com/fulldecent/cameralife
Руководство разработчика объясняет, как MVC организован и применяется в файле: https://github.com/fulldecent/cameralife/blob/master/CONTRIBUTING.md, но он кратко излагается ниже.
Файловое хранилище:
/.htaccess – отправляет все запросы в index.php /index.php – устанавливает автозагрузчик PSR-4 и отправляет все запросы контроллеру /vendor/ – материал, который вы получаете от Composer /assets/ – изображения и файлы css (не стесняйтесь использовать /images/ and /css/ ) /caches/ – временные файлы (не стесняйтесь перемещать это за пределами веб-сайта) /photos/ – пожалуйста, игнорируйте, это другое место, где я храню пользовательский контент, характерный для этого приложения для обмена фотографиями /sources/Controllers/ – цель маршрутизации для каждого запроса URL-адреса /sources/Models/ – все модели данных /sources/View/ – Controllers используют их и передают в Models , они обычно печатают HTML