Что такое шаблон HMVC?
Читая документацию Kohana, я обнаружил, что основное отличие в версии 3.0 состоит в том, что она следует шаблону HMVC вместо MVC, как версия 2.x. Страница об этом в документах Коханы и в википедии не дала мне ясного представления.
Итак, вопрос: что такое шаблон HMVC и чем он отличается от MVC?
5 ответов
Сэм де Фрейссинет (один из разработчиков 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-каналов в Твиттере или блоге или отображение содержимого корзины покупок для веб-сайта электронной коммерции. По сути, это часть контента, которая должна отображаться на нескольких страницах и, возможно, даже в разных местах, в зависимости от контекста основного HTTP-запроса.
Традиционные инфраструктуры MVC, как правило, не дают прямого ответа для этих типов структур содержимого, поэтому люди обычно заканчивают тем, что дублируют и переключают макеты, используют собственные помощники, создают свои собственные структуры виджетов или библиотечные файлы или извлекают несвязанные данные из основного запрошенного Контроллер для проталкивания в View и визуализации в частичном. Ни один из них не является особенно хорошим вариантом, потому что ответственность за рендеринг определенного фрагмента контента или загрузку требуемых данных заканчивается утечкой в несколько областей и дублированием в местах, где они используются.
HMVC, или, в частности, возможность отправлять подзапросы контроллеру для выполнения этих обязанностей, является очевидным решением. Если вы думаете о том, что делаете, это точно соответствует структуре контроллера. Вам необходимо загрузить некоторые данные о комментариях и отобразить их в формате HTML. Таким образом, вы отправляете запрос в комментарии Controller с некоторыми параметрами, он взаимодействует с моделью, выбирает представление, а представление отображает содержимое. Единственное отличие состоит в том, что вы хотите, чтобы комментарии отображались внутри, под статьей блога, которую пользователь просматривает, вместо полностью отдельной страницы полных комментариев (хотя с подходом HMVC вы можете фактически обслуживать как внутренние, так и внешние запросы с помощью одного и того же контроллера и "убивать" "Две птицы одним камнем", как говорится). В этом отношении HMVC действительно является естественным побочным продуктом стремления к повышению модульности кода, возможности повторного использования и поддержанию лучшего разделения задач. Это точка продажи HMVC.
Таким образом, хотя статью TechPortal Сэма де Фрейссинета о расширении масштабов с помощью HMVC интересно подумать, это не то, где 90%+ людей, использующих интегрированные среды HMVC, получат от этого реальные, практические, повседневные преимущества.
HMVC тесно связан с "компонентным" подходом к диспетчеризации. По сути, вместо одного диспетчера, который делегирует контроллеру, каждый контроллер может действовать как сам диспетчер. Это дает вам иерархию контроллеров. Конструкция более гибкая и обеспечивает лучшую инкапсуляцию кода, но за счет более высокой абстракции. Konstrukt разработан вокруг этой модели.
Смотрите также этот ответ: https://stackru.com/questions/115629/simplest-php-routing-framework/120411
В Kohana, по крайней мере, HMVC-запрос - это HTTP-запрос, который обслуживается "внутренне": вместо того, чтобы отправляться по сети, он маршрутизируется, отправляется и обрабатывается самой платформой. Сходство названий "HMVC" и "MVC" сбивает с толку тем, что оно предполагает основную связь между терминами, которых на самом деле не существует: одно не является второстепенным вариантом или модификацией другого, это совершенно разные вещи. (HMVC также описывается как Ajax без HTTP-запроса на стороне клиента.) Кохана подчеркивает и поддерживает "HMVC", что означает, что среда имеет сильную поддержку основанной на HTTP сервис-ориентированной архитектуры.
Преимущество этого архитектурного шаблона заключается в том, что, поскольку для внутренних и внешних запросов используется одно и то же "соглашение о вызовах", тривиально конвертировать "внутренние" запросы на обслуживание в "внешние" запросы или наоборот, когда возникает такая необходимость.
Хотя это разумный архитектурный паттерн, указывать его собственное имя не нужно (Symfony2 описывает ту же концепцию " подзапросов"), и на самом деле имя кажется неправильным: нет особого требования или необходимости, чтобы запросы формировали иерархия (кроме стандартного графа вызовов каждой императивной программы); например, запросы могут быть легко рекурсивными.
[Обновление апрель 2011 г., март 2012 г.: расширен ответ на комментарии.]
HMVC является контроллером представления иерархической модели. В обычном MVC каждый объект GUI имеет свой MVC. Но нет никакой связи между родительским объектом GUI и дочерним объектом GUI в отличие от HMVC. В HMVC каждый объект GUI имеет доступ к своим дочерним объектам, а каждый дочерний объект может получить доступ к своему родительскому объекту.
Таким образом, в каждом представлении есть родительское представление. Через которое оно может получить доступ к родительскому представлению. Ведь в каждом контроллере есть родительский контроллер, через который он может передать событие родительскому контроллеру (если событие не входит в его область действия).
Для подробного описания, пожалуйста, нажмите здесь
Новая ссылка на этот адрес