В рамках MVC, какую структуру каталогов ожидают другие разработчики?

Question

Как правило, рамки MVC имеют структуру, которая выглядит примерно так:

/models
/views
/controllers
/utils

Однако в наборе веб-приложений я решил, что объединение всех моделей, представлений и контроллеров, вероятно, не будет лучшим для ясности, если я не рассмотрю систему как одно приложение вместо набора приложений. Однако некоторые вещи связывают каждое «приложение» вместе, например, понятие пользователей и ролей пользователей.

Итак, у меня есть три возможных решения:

(1) Делайте то, что я на самом деле не хочу, и держите каждую модель, представление и контроллер вместе, независимо от того, к какому приложению они принадлежат. Это рассматривает пакет как одно приложение, так как они связаны между собой несколькими общими потоками, включая пользователей.

(2) Группировать код по приложению.

/app1
    /models
    /views
    /controllers
    /utils
/app2
    /models
    /views
    /controllers
    /utils

(3) Сгруппируйте код по типу, чтобы код утилиты был общим для всех приложений.

/models
    /app1
    /app2
/views
    /app1
    /app2
/controllers
    /app1
    /app2
/utils

Есть ли вариант, который я пропустил? Что будет наиболее логичной схемой для будущих разработчиков? Я лично предпочитаю 2 и 3, но, возможно, большинство людей ожидают 1.

Answer 1

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

/app1
   /models
   /views
   /controllers
   /utils
/app2
   /models
   /views
   /controllers
   /utils
/common
   /models
   /views
   /utils

Answer 2

Кажется, что 2) будет вашим лучшим вариантом, если вы хотите разделить приложения. У вас также может быть папка «/ common» на уровне «/ app #» для общих ресурсов для всех приложений ... например, для общего класса утилит или чего-то еще.

Answer 3

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

Answer 4

Если ваши приложения обмениваются данными, может иметь смысл (для меня) сгруппировать модели вместе.

Однако для представлений и контроллеров, вероятно, имеет смысл разделять их, так как я предполагаю, что они имеют отдельную бизнес-логику и презентации.

Кроме того, если ваши приложения хранятся отдельно в управлении версиями (вы используете контроль версий, верно? :), это затрудняет реализацию первого или третьего варианта.

Итак, учитывая все обстоятельства, я бы, вероятно, разделил приложения на верхнем уровне, как во втором примере.