Я сейчас нахожусь в процессе разработки моей собственной PHP 5.3 HMVC-фреймворка под названием Alloy . Поскольку я вложил значительные средства в HMVC и продал его, я подумал, что могу предложить другую точку зрения и, возможно, лучшее объяснение того, почему следует использовать HMVC и какие преимущества он приносит.
Самым большим практическим преимуществом использования архитектуры HMVC является «виджетизация» структур контента. Примером могут быть комментарии, рейтинги, отображение RSS-каналов в Твиттере или блоге или отображение содержимого корзины покупок для веб-сайта электронной коммерции. По сути, это часть содержимого, которое необходимо отображать на нескольких страницах и, возможно, даже в разных местах, в зависимости от контекста основного HTTP-запроса.
Традиционные инфраструктуры MVC, как правило, не дают прямого ответа для этих типов структур содержимого, поэтому люди обычно заканчивают тем, что дублируют и переключают макеты, используя собственные помощники, создавая свои собственные структуры виджетов или библиотечные файлы, или извлекая несвязанные данные из основной запрашиваемый контроллер для проталкивания в View и рендеринга в частичном. Ни один из них не является особенно хорошим вариантом, потому что ответственность за рендеринг определенного фрагмента контента или загрузку требуемых данных заканчивается утечкой в несколько областей и дублированием в местах, где они используются.
HMVC, или, в частности, возможность отправлять подзапросы контроллеру для выполнения этих обязанностей, является очевидным решением. Если вы думаете о том, что вы делаете, это точно соответствует структуре контроллера. Вам необходимо загрузить некоторые данные о комментариях и отобразить их в формате HTML. Таким образом, вы отправляете запрос в комментарии Controller с некоторыми параметрами, он взаимодействует с моделью, выбирает представление, а представление отображает содержимое. Единственное отличие состоит в том, что вы хотите, чтобы комментарии отображались внутри, под статьей блога, которую пользователь просматривает, вместо полностью отдельной страницы полных комментариев (хотя с подходом HMVC вы можете фактически обслуживать как внутренние, так и внешние запросы с помощью одного и того же контроллера и «убивать» «Две птицы одним камнем», как говорится). В этом отношении HMVC действительно является естественным побочным продуктом стремления к повышению модульности кода, возможности повторного использования и поддержанию лучшего разделения задач. Это точка продажи HMVC.
Итак, хотя Статья Сэма де Фрейссинета на TechPortal о масштабировании с помощью HMVC интересно подумать, это не то, где 90% + людей, которые используют HMVC-фреймворки, получат реальные, практичные, дневные сегодняшние выгоды от этого.