Что такое паттерн HMVC?

Читая документацию Kohana, я обнаружил, что основное отличие версии 3.0 заключается в том, что она следует шаблону HMVC, а не MVC, как это делает версия 2.x. Страница об этом в документации Коханы и страница в Википедии на самом деле не дали мне четкого представления.

Итак, вопрос: что такое шаблон HMVC и чем он отличается от MVC?

Сэм де Фрейсине (один из разработчиков Kohana) написал довольно подробную статью о HMVC , о том, что это такое и как его можно использовать.

Ссылка мертва: новая ссылка - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

В настоящее время я занимаюсь разработкой собственного фреймворка PHP 5.3 HMVC под названием Alloy . Поскольку я сильно инвестирую и продаю HMVC, я подумал, что могу предложить другую точку зрения и, возможно, лучшее объяснение того, почему следует использовать HMVC и какие преимущества он приносит.

Самым большим практическим преимуществом использования архитектуры HMVC является «виджетизация» структур контента. Примером могут быть комментарии, рейтинги, отображение RSS-канала Twitter или блога или отображение содержимого корзины покупок для веб-сайта электронной коммерции. По сути, это фрагмент контента, который необходимо отображать на нескольких страницах и, возможно, даже в разных местах, в зависимости от контекста основного HTTP-запроса.

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

HMVC или, в частности, возможность отправлять подзапросы контроллеру для выполнения этих обязанностей - очевидное решение. Если вы думаете о том, что делаете, это точно соответствует структуре контроллера. Вам необходимо загрузить некоторые данные о комментариях и отобразить их в формате HTML. Итак, вы отправляете запрос контроллеру комментариев с некоторыми параметрами, он взаимодействует с моделью, выбирает представление, а представление отображает содержимое. Единственная разница в том, что вы хотите, чтобы комментарии отображались встроенными под статьей блога, которую просматривает пользователь, а не на полностью отдельной странице с полными комментариями (хотя с подходом HMVC вы можете фактически обслуживать как внутренние, так и внешние запросы с одним и тем же контроллером и "kill два зайца одним выстрелом », как говорится). В этой связи, HMVC - это просто естественный побочный продукт стремления к повышенной модульности кода, возможности повторного использования и поддержанию лучшего разделения проблем. ЭТО - точка продажи HMVC.

Так что, хотя статья Сэма де Фрейссине на TechPortal о масштабировании с помощью HMVC интересна для размышлений, это не то место, где 90% + людей, использующих фреймворки HMVC, собираются получить от этого реальную, практическую, повседневную пользу.

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

См. Также этот ответ: /programming/115629/simplest-php-routing-framework/120411#120411

В Kohana, по крайней мере, запрос HMVC - это HTTP-запрос, который обслуживается «внутри»: вместо того, чтобы отправляться по сети, он маршрутизируется, отправляется и обрабатывается самой структурой. Сходство названий «HMVC» и «MVC» сбивает с толку, поскольку предполагает основополагающую связь между терминами, которой фактически не существует: один не является второстепенным вариантом или модификацией другого, это совершенно разные вещи. (HMVC также описывается как Ajax без HTTP-запроса на стороне клиента.) Акцент Kohana и поддержка «HMVC» означает, что структура имеет сильную поддержку сервис-ориентированной архитектуры на основе HTTP.

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

Хотя это разумный архитектурный шаблон, давать ему собственное имя кажется излишним (Symfony2 описывает ту же концепцию « подзапросы »), и на самом деле имя кажется неправильным: нет особого требования или необходимости, чтобы запросы формировали иерархия (кроме стандартного графа вызовов каждой императивной программы); например, запросы могут легко быть рекурсивными.

[ Обновление, апрель 2011 г., март 2012 г.: ответ расширен в ответ на комментарии.]

HMVC - это контроллер представления иерархической модели. В обычном MVC каждый объект GUI имеет свой MVC, но в отличие от HMVC, нет никакой связи между родительским объектом GUI и дочерним объектом GUI. В HMVC каждый объект GUI имеет доступ к своим дочерним объектам, и каждый дочерний объект может получить доступ к своему родительскому объекту.

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

Для подробного описания нажмите здесь

Новая ссылка - этот адрес