В веб-проекте MVC у меня есть следующая структура:
mymvc/ -> Project root.
public/ -> Document root. The only one folder accessible from web.
assets -> Client-side assets. NOT ONLY for global themes and libraries, BUT ALSO for each specific "view" controlled by the "src/Application" components.
css/
js/
images/
...
index.php -> Application's entry point.
src/ -> UI layer rules.
Application/
Controller/
View/
ViewModel/
Dispatcher/ -> Application dispatching - route matching, dispatching to the specified controller, etc.
... -> Other classes used by the components in the "src/Application" folder.
templates/ -> Layout and template files.
Примечание. Все компоненты модели домена (сущности, репозитории, средства отображения данных, службы и т. Д.) Находятся в папке за пределами mymvc
каталог, так что они могут быть доступны любому другому приложению.
Я много думал на самом деле о следующих двух шагах:
templates
каталог для src/Application
папка.assets
каталог для src/Application
, чтобы создать псевдоним /assets/
в конфигурации веб-сервера (Apache) — указание на перемещенную папку и предоставление полного доступа к ней из внешнего мира.Глобально используемые ресурсы, такие как темы CSS, коды библиотек JS, фоновые изображения и т. Д., Могут по-прежнему находиться в public
директория — явно не в папке с именем или псевдонимом assets
,
Я действительно считаю эти два шага очень хорошей идеей, потому что, на мой взгляд, обе папки содержат ресурсы, связанные со структурой из src/Application
,
Итак, вместо того, чтобы иметь что-то вроде этого:
src/Application/Controller/AboutUs.php
public/assets/js/AboutUs.js
templates/AboutUs/[multiple-layout-and-template-files]
,структура, подобная следующей, кажется намного лучше:
src/Application/Controller/AboutUs.php
src/Application/assets/js/AboutUs.js
src/Application/templates/AboutUs/[multiple-layout-and-template-files]
,Но, изучив множество веб-фреймворков, я понял, что все они сохраняют две папки (templates
а также assets
) полностью отделен от папки приложения.
Поэтому я хотел бы спросить: есть ли какие-то конкретные причины, по которым мое предлагаемое перемещение двух каталогов не может или не должно быть сделано?
Спасибо.
Все зависит от того, чего вы хотите достичь, и каков ваш рабочий процесс. Похоже, вы работаете в PHP — стоит взглянуть на не-PHP фреймворки, такие как Ruby on Rails.
Как правило, вы хотите, чтобы выходная папка была «только для чтения» — разработчик не должен редактировать файлы вручную, вместо этого для сборки и развертывания конвейеров запускаются такие инструменты, как Gradle, для преобразования файлов SASS / LESS и JS (из /source
папку) в CSS и минимизированный / сцепленный Javascript и поместите их в правильное место в /public
, Конвейеры сборки и развертывания часто имеют разные конфигурации для разработки и производственных сборок (например, минимизация только для производства).
В Ruby on Rails структура в основном, как вы описываете, «намного лучше», за исключением того, что «templates» — это папка под «views», называемая «layout». Есть этап сборки (который выполняется автоматически), который преобразует различные файлы ресурсов (SASS / LESS, JS и т. Д.).
Вы можете увидеть подробное описание структуры каталогов Ruby on Rails. Вот. Структура каталогов Джанго объясняется Вот.
Отвечая на вопросы в ваших комментариях:
/app/assets/javascript
с и /app/assets/stylesheets
; в этих папках есть один файл для каждого представления, а также файлы уровня приложения. Это делает ваш процесс сборки красивым и простым — у вас есть всего две папки, о которых вам нужно беспокоиться, и вам не нужно изменять свою сборку каждый раз, когда вы создаете новое представление./app/views
, Представления уровня приложения живут в папке с именем /app/views/layouts
— на самом деле они ничем не отличаются от шаблонов на уровне страниц, поэтому перемещение их из этой папки, похоже, не дает особых результатов, тогда как хранение всего в одной папке верхнего уровня упрощает сборку и настройку.Так что нет, нет причин делать то, что вы предлагаете.
На мой взгляд, каждый может использовать структуру, которая подходит ему / ей лучше всего.
В последние годы я много работал с CodeIgniter и сам занимался жонглированием файлами и папками. В конце я считать У меня есть структура, как мне нравится 🙂
Для папки приложения я, в основном, просто придерживаюсь рекомендуемой (базовой) структуры, как в их руководстве и учебных пособиях.
Это выглядит так:
- versionX
- application
- config
- controllers
- assets // Folder to keep asset specific controllers
css.php
js.php // These controllers are bundling all resources and returning it as css, js or image file. Images can be cropped etc by params in url. Framework routes urls as domain.com/css/stylesheet.css to the css.php controller etc
img.php
documents.php // normal controller files
users.php
...
- core // core (controller) files from which controllers can extend
APP_Controller.php
APP_AssetController.php
...
- helpers // Holds files with functions that you can use everywhere in the app.
- libraries // Holds library files and folders
PasswordHash.php
Permissions.php
Template.php
Twitter.php
...
- models // holds files with all DB logic (one file per DB table in my case, join tables not included)
- public
- css
- js
- components // javascript files for specific (large) page element(s)
modal.js
timeline.js
- controllers // one js file per controller for controller specific js code
documents.js
users.js
- resources // all libraries from 3rd party (Bootstrap, jQuery, ...)
- uploads // user generated content (folder divided per file use/ origin)
- themes
- blueSky
- views
- layouts // app level views
- partials // app level partials (main navs, footers, ...)
- documents // a folder per controller
- modals // modals used at document controller
_merge_document.php
_split_document.php
- partials
_form.php // for adding and editing documents
_drawer.php // submenu for document controller
index_view.php
create_view.php
edit_view.php
...
- users
Надеюсь, это даст вам представление о том, как я это делаю. Но вы действительно должны делать то, что вам нравится больше всего. Нет ничего хуже, чем просматривать что-то, что вам не нравится.
Единственное, что я бы порекомендовал, — это сохранить пространство имен равным структуре каталогов, чтобы автозагрузка была простой. Оттуда языку все равно, как организован код. два ограничения — это пространства имен и каталоги: они иерархические. Таким образом, это определяет, что вы можете классифицировать код только в иерархической структуре.
Актуальная проблема заключается в том, что иерархическая классификация это проблема сама по себе. Объекты могут быть классифицированы разными способами. К счастью, PHP не зависит от классификации, так почему же люди не могут быть одинаковыми? Потому что мы на самом деле думаем о коде и объектах. Мы ищем их, используем их, воспитываем их. Это просто вопрос личного опыта и вкуса, каковы ваши самые сильные ассоциации с определенным поведением объекта?
Есть еще одна вещь, которую следует учитывать: «Ад — это другие люди.»
Поддержание совместимости вашей классификации с другими, как, например, с платформой Symphony, пригодится, как только ваш код начнет зависеть от этой конкретной среды. Или схема классификации других может быть чем-то, что вы не готовы подчинить.
В любом случае, Нет причины не делать то, что ты хочешь. Если позже вы передумаете, по крайней мере, вы сами поймете, почему вы это изменили, и вы извлечете уроки из этого.