Причины отсутствия компактной структуры приложения MVC?

В веб-проекте 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 каталог, так что они могут быть доступны любому другому приложению.

Я много думал на самом деле о следующих двух шагах:

  1. Переместить templates каталог для src/Application папка.
  2. Переместить 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) полностью отделен от папки приложения.

Поэтому я хотел бы спросить: есть ли какие-то конкретные причины, по которым мое предлагаемое перемещение двух каталогов не может или не должно быть сделано?

Спасибо.

12

Решение

Все зависит от того, чего вы хотите достичь, и каков ваш рабочий процесс. Похоже, вы работаете в 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. Вот. Структура каталогов Джанго объясняется Вот.

Отвечая на вопросы в ваших комментариях:

  • Куда должны идти файлы скриптов SASS / LESS / JS / Coffee? — Вам решать. В Rails они живут в /app/assets/javascriptс и /app/assets/stylesheets; в этих папках есть один файл для каждого представления, а также файлы уровня приложения. Это делает ваш процесс сборки красивым и простым — у вас есть всего две папки, о которых вам нужно беспокоиться, и вам не нужно изменять свою сборку каждый раз, когда вы создаете новое представление.
  • Как мне структурировать свои представления — у меня есть представления на уровне приложений и определенные просмотры страниц. Опять же — в основном вопрос удобства. В Rails все шаблоны — живут под /app/views, Представления уровня приложения живут в папке с именем /app/views/layouts — на самом деле они ничем не отличаются от шаблонов на уровне страниц, поэтому перемещение их из этой папки, похоже, не дает особых результатов, тогда как хранение всего в одной папке верхнего уровня упрощает сборку и настройку.

Так что нет, нет причин делать то, что вы предлагаете.

5

Другие решения

На мой взгляд, каждый может использовать структуру, которая подходит ему / ей лучше всего.

В последние годы я много работал с 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

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

2

Классифицируйте свой код

Единственное, что я бы порекомендовал, — это сохранить пространство имен равным структуре каталогов, чтобы автозагрузка была простой. Оттуда языку все равно, как организован код. два ограничения — это пространства имен и каталоги: они иерархические. Таким образом, это определяет, что вы можете классифицировать код только в иерархической структуре.

Актуальная проблема заключается в том, что иерархическая классификация это проблема сама по себе. Объекты могут быть классифицированы разными способами. К счастью, PHP не зависит от классификации, так почему же люди не могут быть одинаковыми? Потому что мы на самом деле думаем о коде и объектах. Мы ищем их, используем их, воспитываем их. Это просто вопрос личного опыта и вкуса, каковы ваши самые сильные ассоциации с определенным поведением объекта?

Есть еще одна вещь, которую следует учитывать: «Ад — это другие люди.»

Поддержание совместимости вашей классификации с другими, как, например, с платформой Symphony, пригодится, как только ваш код начнет зависеть от этой конкретной среды. Или схема классификации других может быть чем-то, что вы не готовы подчинить.

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

1
По вопросам рекламы ammmcru@yandex.ru
Adblock
detector