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