¿Cuál es el patrón HMVC?

Leyendo la documentación de Kohana, descubrí que la principal diferencia en la versión 3.0 es que sigue el patrón HMVC en lugar de MVC como lo hace la versión 2.x. La página sobre esto en los documentos de Kohana y la de Wikipedia no me dio una idea clara.

Entonces pregunta: ¿cuál es el patrón HMVC y en qué se diferencia de MVC?

Sam de Freyssinet (uno de los desarrolladores de Kohana) escribió un artículo bastante profundo sobre HMVC , qué es y cómo se puede usar.

Link is dead: New Link - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

Actualmente estoy en el proceso de desarrollar mi propio framework PHP 5.3 HMVC llamado Alloy . Dado que estoy fuertemente invertido y vendido en HMVC, pensé que podría ofrecer un punto de vista diferente, y tal vez una mejor explicación de por qué debería usarse HMVC y los beneficios que trae.

El mayor beneficio práctico de usar una arquitectura HMVC es la "widgetización" de las estructuras de contenido. Un ejemplo podría ser comentarios, calificaciones, pantallas de feed RSS de Twitter o blog, o la visualización del contenido del carrito de compras para un sitio web de comercio electrónico. Es esencialmente un contenido que debe mostrarse en varias páginas, y posiblemente incluso en diferentes lugares, según el contexto de la solicitud HTTP principal.

Los marcos tradicionales de MVC generalmente no proporcionan una respuesta directa para este tipo de estructuras de contenido, por lo que las personas generalmente terminan duplicando y cambiando diseños, utilizando ayudantes personalizados, creando sus propias estructuras de widgets o archivos de biblioteca, o extrayendo datos no relacionados de los principales solicitados Controlador para pasar a la Vista y renderizar de forma parcial. Ninguna de estas opciones es particularmente buena, porque la responsabilidad de presentar un contenido particular o cargar los datos requeridos termina por filtrarse en múltiples áreas y duplicarse en los lugares donde se usa.

La solución obvia es HMVC, o específicamente la capacidad de enviar solicitudes secundarias a un controlador para que se encargue de estas responsabilidades. Si piensa en lo que está haciendo, se ajusta exactamente a la estructura del controlador. Debe cargar algunos datos sobre los comentarios y mostrarlos en formato HTML. Por lo tanto, envía una solicitud al controlador de comentarios con algunos parámetros, interactúa con el modelo, selecciona una vista y la vista muestra el contenido. La única diferencia es que desea que los comentarios se muestren en línea, debajo del artículo del blog que está viendo el usuario en lugar de una página de comentarios completa completamente separada (aunque con un enfoque HMVC, en realidad puede atender tanto las solicitudes internas como las externas con el mismo controlador y "kill" dos pájaros de un tiro ", como dice el refrán). A este respecto, HMVC es realmente un subproducto natural de luchar por una mayor modularidad del código, reutilización y mantener una mejor separación de las preocupaciones. ESTE es el punto de venta de HMVC.

Entonces, si bien es interesante pensar en el artículo TechPortal de Sam de Freyssinet sobre el escalamiento horizontal con HMVC, no es donde más del 90% de las personas que usan marcos HMVC obtendrán beneficios reales, prácticos y cotidianos.

HMVC está estrechamente relacionado con el enfoque "basado en componentes" para el despacho. Básicamente, en lugar de tener un único despachador, que delega en un controlador, cada controlador puede actuar como un despachador. Esto le da una jerarquía de controladores. El diseño es más flexible y provoca una mejor encapsulación del código, pero a un precio de mayor abstracción. Konstrukt está diseñado en torno a este patrón.

Consulte también esta respuesta: /programming/115629/simplest-php-routing-framework/120411#120411

En Kohana, al menos, una solicitud HMVC es una solicitud HTTP que se atiende "internamente": en lugar de emitirse a través de la red, es enrutada, despachada y manejada por el propio marco. La similitud de los nombres "HMVC" y "MVC" es confusa, ya que sugiere una conexión subyacente entre los términos que de hecho no existe: uno no es una variante menor o una modificación del otro, son cosas completamente diferentes. (HMVC también se describe como Ajax sin la solicitud HTTP del lado del cliente). El énfasis de Kohana y el soporte para "HMVC" significa que el marco tiene un fuerte soporte para una arquitectura orientada a servicios basada en HTTP.

La ventaja de este patrón arquitectónico es que, dado que se utiliza la misma "convención de llamada" para solicitudes internas y externas, es trivial convertir las solicitudes de servicio "internas" en solicitudes "externas" o viceversa, según sea necesario.

Si bien este es un patrón arquitectónico sensible, darle su propio nombre parece innecesario (Symfony2 describe el mismo concepto " sub-solicitudes "), y de hecho el nombre parece ser un nombre inapropiado: no hay ningún requisito particular o necesidad de que las solicitudes formen un jerarquía (que no sea el gráfico de llamadas estándar de cada programa imperativo); las solicitudes podrían ser fácilmente recursivas, por ejemplo.

[ Actualización de abril de 2011, marzo de 2012: se amplió la respuesta en respuesta a los comentarios.]

HMVC es un controlador jerárquico de vista de modelo. En MVC normal, cada objeto GUI tiene su MVC, pero no hay ninguna relación entre el objeto GUI principal y el objeto GUI secundario a diferencia de HMVC. En HMVC, cada objeto GUI tiene acceso a sus objetos secundarios y cada objeto secundario puede acceder a su objeto primario.

Entonces, en cada vista hay una vista primaria, a través de la cual puede acceder a ella. En cada controlador hay un controlador principal a través del cual puede pasar el evento al controlador principal (si el evento no está dentro de su alcance).

Para una descripción detallada, haga clic aquí

Nuevo enlace es esta dirección