Qual é o padrão HMVC?


130

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?


30
Uma discussão sobre esse mesmo tópico ocorreu nos fóruns de Kohana. Você pode achar útil
Sampson

Respostas:


86

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/


obrigado por um bom link, também confira esta javaworld.com/jw-07-2000/jw-0721-hmvc.html
Owais Qureshi


Os links sempre morrerão! publicar conteúdo em vez de link.
Loki

58

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.


5
Sim, foi assim que eu o imaginei no uso no mundo real, mas desse ponto de vista o nome não é adequado, pois o H no HMVC é enganoso (não há hierarquia real).
Matteo Riva

2
Sim, você faz um bom argumento. Na verdade, eu compartilho esse ponto de vista e dei outro nome - "Nested MVC" - em uma apresentação que fiz no Alloy no Confoo 2011. Está no Slideshare, slide 20: slideshare.net/vlucas/alloy-hmvc-php- quadro
Vance Lucas

Como o HMVC lidaria com a necessidade de vários retornos da árvore de módulos? Por exemplo, agrupando o conteúdo da cabeça / corpo / rodapé, dependências JS / Css e inter-relações entre os módulos. Eventos? Hooks? Uma estrutura de página singleton? Objetos de retorno estruturados?
Scipilot

1
Esta resposta é uma cópia da wikipedia: / en.wikipedia.org/wiki/…
EricG

3
O @EricG parece que alguém copiou a resposta que eu dei aqui e a adicionou à Wikipedia (não fui eu). Verifique a seção "Referências" na parte inferior do artigo da Wikipedia - ela contém links para este comentário.
Vance Lucas

7

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


7

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.]


2
Sendo capaz de converter solicitações de serviço 'internas' em menções de solicitações 'externas', você pode expandir com mais facilidade se necessário, ou seja, mover alguns módulos de aplicativos para seu próprio servidor.
Kim Prince

1
sim, tente implementar um serviço da Web interno com e sem ele, apenas para ver se ele realmente "realmente não importa tanto".
Kemo

@ Kemo Eu acho que é uma bela arquitetura, só acho o nome confuso e implica que Kohana está fazendo algo particularmente incomum.
MJS

Não tenho certeza de como sua resposta é útil. Você não está respondendo à pergunta apenas reclamando sobre o nome e que é desnecessário (o que é bom).
Dave

4

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


1
a marca de uma boa resposta não é apenas um link sem nenhuma outra informação ou contexto. Você pode gastar sua resposta e resumir a parte relevante da postagem vinculada?
Kev

1
@Sanjay, alguma razão para você ter alterado o destino do link do artigo HMVC para um no estado de gwt para celular?
Brad Koch

@ Koch..Eu não mudei o link ... mesmo eu não sei quem o mudou .... btw eu o vinculei ao link original.
precisa
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.