Блог

Как правило, каркасные работы 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.

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

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

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

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

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

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

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

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