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

Ответ 1

Все зависит от того, чего вы хотите достичь, и каков ваш рабочий процесс. Вы, кажется, работаете в PHP - стоит посмотреть на фреймворки, отличные от PHP, такие как Ruby on Rails.

Как правило, вы хотите, чтобы выходная папка была "только для чтения" - разработчик не должен вручную редактировать файлы, вместо этого строит и развертывает конвейеры, запуская такие инструменты, как Gradle для преобразования файлов SASS/LESS и JS (из /source папки) в CSS и миниатюрный/объединенный Javascript и поместите их в нужное место в /public. Для построения и развертывания конвейеров часто используются разные конфигурации для разработки и производства (например, для сокращения добычи).

В Ruby on Rails структура в основном описывается как "намного лучше", за исключением того, что "шаблоны" представляют собой папку под "представлениями", называемую "макеты". Там есть шаг сборки (который выполняется автоматически), который преобразует различные файлы активов (SASS/LESS, JS и т.д.).

Вы можете увидеть подробное описание Рубина на структуру каталогов Rails здесь. Структура каталогов Django объясняется здесь.

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

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

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

Ответ 2

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

Я много работал с 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

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

Ответ 3

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

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

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

Есть одна дополнительная вещь, которую следует учитывать: "Ад - это другие люди".

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

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