Оптимальная структура файловой системы для скриптовых приложений MVC

Question

Когда я говорю о языках сценариев, я говорю о таких языках, как Python, Perl и (в моем случае) PHP. После использования CodeIgniter, Zend и множества других увлекательных систем MVC кажется очевидным, что единственное, с чем можно было бы согласиться, - это структура папок (наряду с другими вещами_подобными). Это действительно вызывает у меня проблему, потому что я не могу найти хорошую документацию о преимуществах различных конструкций конструкций. Большинство людей просто рекомендуют один, потому что это то, что они используют без учета улучшений в дизайне.

Одна из вещей, с которыми, я надеюсь, мы все согласимся, заключается в том, что проверка файловой системы на наличие файлов при автоматической загрузке классов - очень плохая практика. Наши классы не должны находиться в одном из 5 возможных мест, вызывающих множество проверок file_exists () для каждой загружаемой нами библиотеки.

Так или иначе, я пытаюсь собрать структуры каталогов, которые я могу сравнить, чтобы найти лучшие практики при планировании приложений, которые:

1. Основаны на ООП, что, скорее всего, означает MVC
2. являются международными по объему и поддержке языковых файлов / переводов
3. Открыты для модулей / плагинов, так что полные пакеты могут быть сброшены в нашу кодовую базу
4. Четко определите, что происходит и где искать данные классы
5. Возможна поддержка нескольких сайтов, работающих в одной структуре (см. / Каталоги сайтов ниже)

Итак, вот что у меня есть. Помните, что libs - это просто термин, обозначающий вашу основную директорию библиотеки / класса и может даже содержать модели в зависимости от структуры папок. Кроме того, я исключил любой тип статического контента (JS / CSS / images), так как этот материал действительно запоздалый и не имеет отношения к нашему серверному коду - он может быть даже на другом сервере! То же самое с кешами, загрузками файлов, lang и всем другим сгенерированным контентом.

/controllers
/views
/models
/libs
/config
index.php

Этот вид напоминает мне фреймворк Zend, который собирает все в одну папку libs (которая также включает в себя подпапки, чтобы упорядочить вещи). Работает только для одного сайта.

---

/libs
/site
    /controllers
    /views
    /models
    /config
index.php

Это будет многосайтовая версия вышеуказанной структуры.

---

/libs
/functions
/site
    /controllers
    /models
    /views
    /config
/site2
    /controllers
    /models
    /views
    /config
/modules
    /user
        /controllers
        /models
        /views
index.php

Это будет версия, которая позволит использовать несколько сайтов и . Модули будут самостоятельными приложениями MVC, такими как форум, который будет включать бизнес-логику, CRUD и представления.

Так есть ли у кого-нибудь совершенная структура , которой они могли бы поделиться или помочь мне выбрать хороший расширяемый дизайн?

Answer 1

Вот слишком сложный пример, который хорошо организовывает все - за счет ясности и простоты.

_{(источник: gsdesign.ro )}

Answer 2

Не особо рекомендую symfony , а скорее это подход, который я считаю довольно хорошим (но не "идеальным")

Позволяет:

• I18N
• Несколько сред (dev, qa, prod и т. Д.)
• Внешние библиотеки
• Плагины
• Несколько сайтов (доменов или иным образом)
• Пакетная обработка (задачи командной строки)
• Юнит-тесты
• Документация
• Вход
• Кэширование

Кроме того, среди взлетов и падений Symfony, я думаю, что это очень хорошо, это кэширование. И я не имею в виду кэширование шаблонов / представлений - я имею в виду кэширование, подобное компиляции .

Когда проект выполняется в первый раз, symfony создает главный файл библиотечных классов, который при последовательных попаданиях в приложение не только удаляет десятки или даже сотни вызовов статистики за запрос, но и выполняет другие оптимизации, такие как удаление комментарии.

Он также кэширует данные конфигурации и информацию об автозагрузке, которые могут быть настроены в соответствии с вашими потребностями.

Answer 3

Мы используем структуру, аналогичную вашей последней «многосайтовой» опции, для механизма форумов с несколькими сайтами, который мы встроили в дом, и он работает очень хорошо. Вы всегда можете скопировать модули, если вам нужно, и это также дает возможность сайту А немного настроить их модуль, не затрагивая сайт Б.

Когда вы приступаете к практическому применению этого, вы говорите о совершенно отдельных командах, может быть, даже о компаниях, использующих эти два сайта, небольшое разделение - не самое страшное. У нас также есть общая папка модулей, но если вы называете файл в папке модулей сайта тем же, он использует эту версию. Используя это и __autoload (при условии PHP), разработчикам сайта не нужно беспокоиться о том, где находится модуль, чтобы использовать его.