Разновидность архитектурного шаблона MVC, где H означает иерархический.

Проблемы MVC

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

Проблема первая

На практике обычно приходиться оперировать одновременно несколькими моделями, например: статьи, пользователи, комментарии. В принципе, это не критично, паттерн MVC это предусматривает, но это увеличивает количество зависимостей — вид и контроллер зависят более чем от одной модели, а от одной модели зависят более одного вида и контроллера.

Проблема вторая

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

Проблема третья

Иногда действия надо выполнить не над одной моделью, а над несколькими одновременно. Например, при удалении пользователя надо удалить все его статьи и комментарии. В результате приходится создавать контроллер, который описывает операции не только над моделью к которой он относится (в примере — пользователи), но над моделями к которым непосредственного отношения он не имеет. Таким образом появляются не очевидные зависимости.
 

Основная идея HMVC

Как же устранить эти проблемы? Поскольку проблемы возникают из-за того, что вместо MVC получается что-то наподобие MMMVVVCC, где каждая модель вид и контроллер могут принадлежать разным подсистемам, ответ очевиден — вернуться к MVC в котором есть лишь по одной модели, виду и контроллеру.

Итак, первый принцип HMVC: в приложении используются только жестко фиксированные триады модель-вид-контроллер, которые взаимодействуют с остальными подсистемы исключительно через контроллер.

Из этого выплывает второй принцип: для организации более сложных комбинаций используются иерархии триад.
 

На первый взгляд, может показаться, что для возможности реализации HMVC достаточно возможности вызова контроллера из другого контроллера. Но в веб-приложении поведение зависит не просто от команды переданной контроллеру, а от http-запроса в целом. И модель и вид могут сами анализировать запрос и некоторым образом изменять свое поведение. Поэтому требуется возможность передать запрос другому контроллеру, причем не обязательно тот же, что был получен.

Масштабирование HMVC-приложения

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

--