Processamento Multi MVC vs. Processo Single MVC

5

Eu trabalhei bastante extensivamente com o cakephp framework MVC, no entanto eu estou achando que eu prefiro ter minhas páginas conduzidas pelo MVC múltiplo do que por apenas um MVC. Meu motivo é principalmente para manter um princípio mais seco.

No CakePHP MVC: você chama um URL que chama um único MVC, que chama o layout. O que eu quero é: você chama um URL, ele processa um layout, que então chama vários MVCs por componente / bloco de html na página.

Quando você compara os componentes JavaScript, AJAX e a renderização HTML do lado do servidor, parece que o método mais consistente para criar páginas é através de blocos de componentes ou visualizações HTML. Dessa forma, o bloco de visão pode estar situado no servidor ou no cliente.

Isso é tecnicamente meu único desacordo com o modelo MVC. Fora disso, as rochas da IMHO MVC!

Minha pergunta é: Quais outros frameworks RAD seguem os mesmos princípios do MVC, mas são direcionados pelo lado do MVC?

Eu olhei para o Django e Ruby on Rails, mas eles parecem ser mais controlados pelo Controller.

O Lift / Scala parece ser um bom ajuste, mas estou interessado em ver o que os outros existem.

    
por lordg 16.06.2011 / 18:48
fonte

5 respostas

3

Acho que o que você está pensando é um conceito chamado HMVC, que significa Controlador de Vista de Modelo Hierárquico.

O que isto significa é que quando você está renderizando sua visão, você é capaz de despachar uma requisição para um controlador completamente diferente e retornar essa visão e ecoar. Ele se comporta exatamente como um pedido de ajax, exceto que ele não passa por http, passa pela estrutura e não faz uma solicitação adicional.

Isso não é comum na maioria dos frameworks, e as pessoas que não conhecem o HMVC não sabem o que estão perdendo. Ele limpa muitos padrões feios que você vê em aplicativos MVC comuns.

Por exemplo, você tem um carrinho de compras em cada página. Não seria bom fazer uma chamada para o controlador do carrinho de compras de dentro do seu código e, em seguida, permitir que ele lide com a renderização e outras coisas? Você pode mostrar diferentes visualizações para diferentes estados. Tentar fazer isso em uma aula ou em um método auxiliar é apenas uma bagunça.

De qualquer forma, o que você veio aqui é um framework que funciona assim. A resposta é Kohana . Veja os documentos relevantes .

Veja um exemplo disso em uso:
Request::factory('shopping_cart/display_items')->execute()-body;

    
por 16.06.2011 / 21:04
fonte
2

Você provavelmente não encontrará um sabor de MVC que envolva um modo de exibição.

Como você sabe, no MVC as Views devem ser o mais "estúpidas" possível para obter uma boa Separação de Preocupações.

A solicitação é roteada para uma ação em um controlador que faz toda a lógica no modelo e decide o que exibir e envia para uma exibição.

Como você pode reutilizar o código e as visualizações do Cliente, não entendo qual aspecto do MVC você está achando incompatível com o princípio DRY?

Se você quiser que cada página cuide de sua própria lógica, o ASP.NET tem o ponto de vista visual e o modelo Page, mas como é essencialmente uma tradução da web do WinForms, sua natureza dirigida pelo estado não é realmente correta para o Web (uma vez que HTTP é stateless), daí a atual popularidade e migração de desenvolvedores para a ASP.NET MVC.

    
por 16.06.2011 / 19:12
fonte
1

Como o StuperUser disse, o MVC é baseado na visão de ser "estúpido" ou "magro", e honestamente, parece que você pode ter um mal-entendido dos fundamentos do MVC em algum lugar (não necessariamente difícil, na minha experiência, desde O MVC pode ser difícil de entender se não for bem explicado), se você estiver se encontrando copiando código nos controladores.

Dito isso, você pode querer dar uma olhada na estrutura M-V-VM (Modelo, Visualização, Modelo de Visão) que as tecnologias WPF e Silverlight da .Net usam (ou pelo menos usam a partir de 3.5). É baseado no MVC, mas tem algumas de suas próprias regras e pode estar mais próximo do que você está procurando.

    
por 16.06.2011 / 19:35
fonte
1

No CakePHP você pode fazer o que você pede com requestAction . Geralmente não é recomendado devido a problemas de desempenho, mas funciona bem, especialmente com conteúdo em cache.

    
por 17.06.2011 / 02:46
fonte
1

O ASP.NET MVC tem um 'RenderAction' que você pode chamar de dentro do código inline na sua visualização. Eu não gosto disso pessoalmente; Eu prefiro construir modelos compostos em torno de um layout e permitir que os modelos de 'visualização principal' derivem dele.

Eu posso usar um pequeno construtor ou fábrica para instanciar o modelo (composto) para ajudar a instanciar a composição. Isso é principalmente para manter meus controladores limpos de conhecimento sobre outras sub-visões.

Usando essa estratégia, posso fazer com que cada visualização parcial remova o próprio submodelo do modelo composto ou faça com que o layout faça isso para uma exibição parcial.

    
por 17.06.2011 / 02:54
fonte