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