Qual é o padrão HMVC?

Lendo a documentação de Kohana, descobri que a principal diferença na versão 3.0 é que ela segue o padrão HMVC em vez do MVC como a versão 2.x. A página sobre isso nos documentos de Kohana e a da wikipedia não me deu uma ideia clara.

Então, pergunta: qual é o padrão HMVC e como ele difere do MVC?

Sam de Freyssinet (um dos desenvolvedores do Kohana) escreveu um artigo bastante aprofundado sobre o HMVC , o que é e como pode ser usado.

O link está morto: Novo link - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

Atualmente, estou no processo de desenvolver minha própria estrutura PHP 5.3 HMVC chamada Alloy . Como sou investido e vendido pesadamente no HMVC, pensei em oferecer um ponto de vista diferente e talvez uma explicação melhor de por que o HMVC deveria ser usado e os benefícios que ele traz.

O maior benefício prático do uso de uma arquitetura HMVC é a "widgetização" das estruturas de conteúdo. Um exemplo pode ser comentários, classificações, exibições de feed RSS do blog ou do blog ou a exibição do conteúdo do carrinho de compras de um site de comércio eletrônico. É essencialmente uma parte do conteúdo que precisa ser exibida em várias páginas e, possivelmente, mesmo em lugares diferentes, dependendo do contexto da solicitação HTTP principal.

As estruturas MVC tradicionais geralmente não fornecem uma resposta direta para esses tipos de estruturas de conteúdo; portanto, as pessoas geralmente acabam duplicando e alternando layouts, usando auxiliares personalizados, criando suas próprias estruturas de widget ou arquivos de biblioteca ou obtendo dados não relacionados das principais requisições solicitadas. Controlador para avançar até a Visualização e renderizar em parcial. Nenhuma dessas opções é particularmente boa, porque a responsabilidade de renderizar um determinado conteúdo ou carregar os dados necessários acaba vazando para várias áreas e duplicando nos locais em que é usada.

HMVC, ou especificamente a capacidade de enviar sub-solicitações a um Controlador para lidar com essas responsabilidades é a solução óbvia. Se você pensar no que está fazendo, ele se encaixa exatamente na estrutura do controlador. Você precisa carregar alguns dados sobre comentários e exibi-los no formato HTML. Então, você envia uma solicitação aos comentários do Controller com alguns parâmetros, ele interage com o Model, escolhe uma View e a View exibe o conteúdo. A única diferença é que você deseja que os comentários sejam exibidos em linha, abaixo do artigo do blog que o usuário está visualizando, em vez de uma página de comentários completos completamente separada (embora com uma abordagem HMVC, você possa realmente atender a solicitações internas e externas com o mesmo controlador e "kill dois coelhos com uma cajadada ", como diz o ditado). A respeito disso, O HMVC é realmente apenas um subproduto natural da busca por maior modularidade do código, reutilização e manutenção de uma melhor separação de preocupações. Este é o ponto de venda da HMVC.

Portanto, embora seja interessante pensar no artigo TechPortal de Sam de Freyssinet sobre a expansão com o HMVC, não é onde mais de 90% das pessoas que usam as estruturas do HMVC obterão benefícios reais, práticos e diários.

O HMVC está intimamente relacionado à abordagem "baseada em componentes" no envio. Basicamente, em vez de ter um único expedidor, que delega para um controlador, cada controlador pode atuar como um expedidor. Isso fornece uma hierarquia de controladores. O design é mais flexível e causa um melhor encapsulamento de código, mas a um preço de maior abstração. O Konstrukt é projetado com base nesse padrão.

Consulte também esta resposta: /programming/115629/simplest-php-routing-framework/120411#120411

Em Kohana, pelo menos, uma solicitação HMVC é uma solicitação HTTP que é atendida "internamente": em vez de ser emitida pela rede, é roteada, despachada e manipulada pela própria estrutura. A semelhança dos nomes "HMVC" e "MVC" é confusa, pois sugere uma conexão subjacente entre os termos que de fato não existem: um não é uma variante ou modificação menor do outro, são coisas completamente diferentes. (O HMVC também é descrito como Ajax sem a solicitação HTTP do lado do cliente.) A ênfase de Kohana e o suporte ao "HMVC" significa que a estrutura possui forte suporte para uma arquitetura orientada a serviços baseada em HTTP.

A vantagem desse padrão arquitetural é que, como a mesma "convenção de chamada" é usada para solicitações internas e externas, é trivial converter solicitações de serviço "internas" em solicitações "externas" ou vice-versa conforme a necessidade.

Embora esse seja um padrão arquitetural sensato, dar a ele seu próprio nome parece desnecessário (o Symfony2 descreve o mesmo conceito " sub-solicitações ") e, na verdade, o nome parece ser um nome impróprio: não há nenhum requisito ou necessidade específica de que os pedidos formem um hierarquia (que não seja o gráfico de chamadas padrão de todos os programas imperativos); os pedidos podem ser facilmente recursivos, por exemplo.

[ Atualização em abril de 2011, março de 2012: ampliada na resposta em resposta aos comentários.]

O HMVC é um controlador hierárquico de exibição de modelo. No MVC normal, todo objeto da GUI possui seu MVC. Mas não há nenhuma relação entre o objeto da GUI pai e o objeto da GUI filho, diferentemente do HMVC. No HMVC, cada objeto da GUI tem acesso aos seus objetos filhos e cada um dos objetos filhos pode acessar seu objeto pai.

Portanto, em todas as visualizações, há uma visualização principal. Através da qual ele pode acessá-la. Pois em todo controlador existe um controlador pai através do qual ele pode passar o evento para o controlador pai (se o evento não estiver em seu escopo).

Para mais detalhes, clique aqui

Novo link é este endereço