Читая документацию Коханы, я обнаружил, что основное отличие версии 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
В Kohana, по крайней мере, запрос HMVC является HTTP-запросом, который обслуживается «внутренне»: вместо того, чтобы быть выпущенным по сети, он маршрутизируется, отправляется и обрабатывается самой картой. Сходство имен «HMVC» и «MVC» сбивает с толку, поскольку оно предполагает базовую связь между терминами, которые на самом деле не существуют: один не является второстепенным вариантом или модификацией другого, они совершенно разные. (HMVC также описывается как Ajax без HTTP-запроса на стороне клиента.) Приоритет Kohana и поддержка «HMVC» означает, что структура имеет сильную поддержку HTTP-ориентированной сервис-ориентированной архитектуры.
Преимущество этого архитектурного шаблона заключается в том, что, поскольку для внутренних и внешних запросов используется одно и то же «соглашение о вызове», тривиально преобразовать «внутренние» запросы на обслуживание «внешним» запросам или наоборот по мере необходимости.
Несмотря на то, что это разумный архитектурный шаблон, его собственное имя кажется ненужным (Symfony2 описывает ту же концепцию « подпросы »), и на самом деле это имя кажется неправильным: нет особых требований или необходимости, чтобы запросы составляли иерархия (кроме стандартного графика вызовов каждой императивной программы); например, запросы могут быть рекурсивными.
[ Обновление Apr 2011, март 2012: расширенный ответ в ответ на комментарии.]
HMVC является иерархическим контроллером представления модели. В стандартном MVC каждый объект GUI имеет свой MVC. Но нет никакого отношения между родительским GUI-объектом и объектом дочернего GUI, в отличие от HMVC. В HMVC каждый объект GUI имеет доступ к своим дочерним объектам, и каждый из дочерних объектов может обращаться к его родительскому объекту.
Таким образом, во всех представлениях есть родительский вид. Через него он может получить доступ к родительскому представлению. Для каждого контроллера есть родительский контроллер, через который он может передать событие родительскому контроллеру (если событие не входит в его область действия.)
Для получения дополнительной информации, пожалуйста, нажмите здесь
Новая ссылка – это адрес