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

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

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

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

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

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

• Куда должны идти файлы сценариев SASS / LESS / JS / Coffee? - на ваше усмотрение. В Rails они живут в /app/assets/javascript и /app/assets/stylesheets; в этих папках есть по одному файлу для каждого представления, а также файлы уровня приложения. Это делает процесс сборки приятным и простым - у вас есть всего 2 папки, о которых нужно беспокоиться, и вам не нужно изменять свою сборку каждый раз, когда вы создаете новое представление.
• Как мне структурировать свои представления - у меня есть представления на уровне приложения и просмотры определенных страниц. Опять же - в основном вопрос удобства. В Rails все шаблоны - живут под /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, пригодится, когда ваш код начнет зависеть от этой конкретной структуры. Или схема классификации других может быть чем-то, чему вы не желаете подчиняться.

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