Entenda os MVCs e os frameworks Action e Component Based
Postado em 03. jul, 2012 por Adriano Almeida em Arquitetura, Java
É muito comum encontrar desenvolvedores que aprendem componentes do JSF como o Primefaces e o Richfaces e gostariam de usá-las em seus projetos que utilizam frameworks web como o Spring MVC, Struts e VRaptor, porém, isso não é possível. Por que? Entenda os diferentes funcionamentos do MVC, aprenda como funcionam os frameworks e tire para sempre essa e outras dúvidas!
Um @Controller do SpringMVC
Quando trabalhamos com o SpringMVC, tratamos as requisições enviadas pelos usuários dentro de classes conhecidas como Controller. É uma classe simples, anotada com @Controller onde implementamos métodos que tratam a requisição para uma determinada URL, indicada através da anotação @RequestMapping.
@Controller
public class ProdutosController {
@RequestMapping("adicionaProduto")
public void adiciona(Produto p, HttpServletRequest req) {
// pega o produto recebido no request e grava no banco de dados
}
}
Quando a requisição é submetida para o endereço adicionaProduto e envia os parâmetros adequados para preencher o objeto Produto, ele é gravado no banco. Porém, precisamos devolver uma resposta para o usuário, que deverá conter o nome do produto adicionado, então podemos disponibilizar um atributo ao JSP através do request que recebemos no nosso método.
@RequestMapping("adicionaProduto")
public void adiciona(Produto p, HttpServletRequest req) {
// pega o produto recebido no request e grava no banco de dados
req.setAttribute("nome", p.getNome());
}
Então logo após a execução da ação, indicamos para o SpringMVC que o produto-adicionado.jsp deve ser mostrado. Para isso, basta fazermos nosso método retornar uma String com o nome do JSP.
@RequestMapping("adicionaProduto")
public String adiciona(Produto p) {
// pega o produto recebido no request e grava no banco de dados
req.setAttribute("nome", p.getNome());
return "produto-adicionado";
}
Dessa forma, após a execução, o JSP será exibido para o usuário.
<h2>Produto ${nome} adicionado com sucesso</h2>
Onde está o MVC aí?
O mais importante nisso tudo, é notar que existe uma separação clara entre as responsabilidades no tratamento da requisição.
Quando um usuário submete uma requisição para o endereço http://localhost:8080/projeto/adicionaProduto, o SpringMVC a recebe e descobre, de alguma maneira, qual é o @Controller e qual método deve ser responsável por tratá-la. Nesse caso, o SpringMVC está fazendo o papel do Front Controller, que delega a responsabilidade para um Controller secundário, no caso a classe ProdutosController e o método adiciona. Chamamos o responsável por esse trabalho de Controlador.
Os passos do controlador
O próximo passo é a execução das regras de negócio, que podem envolver a execução da persistência das informações, validações e outras tarefas que dizem respeito aos requisitos funcionais da aplicação. Chamamos as classes que fazem esse trabalho de Modelo.
@Controller invoca o Modelo para realizar as regras de negócio
Após a execução do Modelo e de todas as as regras de negócio, o JSP contendo a resposta adequada deve ser exibido para o usuário. Nesse ponto, temos as regras de visualização implementadas, como por exemplo, exibir as informações em vermelho, dada alguma característica. Essas regras ficam todas centralizadas no JSP, que nesse caso, faz um papel que chamamos de Visão, ou seja, é o responsável pelo que o usuário irá visualizar como resultado.
@Controller indica qual visão será devolvida para o usuário
Juntando tudo o que vimos, temos o MVC – Modelo, Visão e Controlador, cujo objetivo é separar as responsabilidades da aplicação, fazendo com que tenhamos um código mais fácil de ser mantido.
Os frameworks Action Based e o MVC Push
No exemplo anterior, os dados que precisam ser disponbilizados para a Visão fazer a exibição são “empurrados” do @Controller. Quando isso acontece, dizemos que estamos usando um estilo de MVC chamado MVC Push, ou seja, que empurra os dados para a Visão utilizar. Atualmente, frameworks que seguem essa estratégia são conhecidos como Action Based (Baseado em Ações).
Esse estilo de MVC é utilizado na grande maioria dos frameworks web, como o SpringMVC (visto aqui), Struts, VRaptor, ASP.NET MVC e inclusive o Rails.
E quando eu trabalho com JSF não acontece a mesma coisa?
Considere uma listagem simples de produtos em uma aplicação JSF, na qual precisaríamos ter o XHTML, chamado produtos.xhtml, para mostrar os dados através de um simples h:dataTable.
<h:dataTable value="#{produtosBean.produtos}" var="p">
<h:column>#{p.nome}</h:column>
</h:dataTable>
Quando acessamos em nosso navegador http://localhost:8080/projeto/produtos.xhtml, novamente o framework, no caso o JSF, é quem recebe a requisição e desencadeia todo um processo para tratá-la de maneira adequada.
O fluxo no JSF e como se encaixa no MVC
No momento em que recebe a requisição ele inicia o processamento do xhtml, o que no nosso caso, logo incidirá na avaliação do h:dataTable, que depende de uma lista de produtos, indicada pela Expression Language #{produtosBean.produtos}. Nesse momento, o processamento está na Visão.
Fluxo no JSF começa pela Visão
A lista de produtos se encontra num Managed Bean, que possui o seu método getProdutos invocado pelo JSF, indicado através do parâmetro value do h:dataTable, para que consiga recuperá-la do banco de dados ou do lugar adequado:
@ManagedBean
public class ProdutosBean {
// atributos e demais métodos
public List getProdutos() {
return repositorio.produtos();
}
}
Nesse caso, o Managed Bean quando solicitado pela Visão como foi no caso do value do h:dataTable, busca junto às suas classes os objetos solicitados, novamente, invocando regras de persistência, de validação e outros. Estamos diante do Modelo da nossa aplicação.
Visão pede pro Managed Bean que invoca o Modelo
Os objetos recuperados pelo Managed Bean são enfim dados à Visão que o solicitou, para que o processamento dela possa continuar e ao final de tudo devolver a resposta para o usuário.
Managed Bean devolve os dados para a Visão, que continua seu processamento. Ao final, o resultado é mostrado para o usuário.
Os frameworks Component Based e o MVC Pull
Quando usamos o JSF, a requisição cai primeiro no Controlador, o JSF, que inicia o processamento pela Visão, que quando necessário, pega os dados através do Managed Bean e invoca as classes necessárias do Modelo e por fim, disponibiliza os dados necessários para a Visão poder continuar o processamento.
Repare que nesse caso, é a Visão quem solicita os objetos necessários para a renderização, ela “puxa” os dados através do Managed Bean. Esse estilo de MVC ficou conhecido como MVC Pull e hoje em dia é mais conhecido por Component Based (Baseado em Componentes), uma categoria que possui frameworks como o JSF e os menos conhecidos Wicket e Tapestry.
Diferenças, vantagens e desvantagens
Há uma clara diferença entre o ciclo de execução de ambos os estilos de MVC, o que inviabiliza, por exemplo, o uso de qualquer biblioteca de componentes do JSF com um framework como o Spring MVC, afinal seu controlador não está preparado e nem foi feito para que a Visão lhe solicite informações.
Quando usamos o MVC Pull, temos um maior acoplamento entre a Visão e o framework MVC, o que pode ser um ponto negativo, porém abre portas para a criação de componentes ricos da tela controlados via código Java.
Já no MVC Push temos o inverso. Conseguimos um grande desacoplamento entre a Visão, mas perdemos a possibilidade de termos componentes ricos controlados por código Java.
Na Caelum, durante o curso FJ-21 estudamos o MVC Push, através do SpringMVC e no FJ-26, estudamos o JSF e o MVC Pull. No curso de arquitetura (assim como neste livro) temos boas discussões sobre o uso ou não de cada um dos estilos.
A Editora Casa do Código publicou o livro de JSF e JPA, onde diversos assuntos são discutidos, inclusive detalhes sobre o JSF e como trabalhar com o MVC Pull.
E você, tem alguma preferência?
Adriano Almeida (Google+)
Mais sobre o autor
39 Respostas para “Entenda os MVCs e os frameworks Action e Component Based”
Trackbacks/Pingbacks
-
-
julho 3, 2012
[...] “É muito comum encontrar desenvolvedores que aprendem componentes do JSF como o Primefaces e o Richfaces e gostariam de usá-las em seus projetos que utilizam frameworks web como o Spring MVC, Struts e VRaptor, porém, isso não é possível. Por que? Entenda os diferentes funcionamentos do MVC, aprenda como funcionam os frameworks e tire para sempre essa e outras dúvidas!” Veja o artigo completo. [...]
-
-
setembro 10, 2012
[...] Saiba mais em: http://blog.caelum.com.br/entenda-os-mvcs-e-os-frameworks-action-e-component-based/ [...]
-
-
setembro 19, 2012
[...] optou por um framework component based, escolheu trabalhar com JSF e ainda não sabe se deve encarar riscos e custos de migrar para a [...]
-
-
setembro 27, 2012
[...] Adriano. Entenda os mvcs e os frameworks action e component based. 2012. Disponível em: http://blog.caelum.com.br/entenda-os-mvcs-e-os-frameworks-action-e-component-based/. Acesso em: 27 set. [...]
ASSINE NOSSO RSS
Arthur Gregorio
03. jul, 2012
ótimo artigo! parabéns!
So fiquei com uma duvida ali no final:
“Na Caelum, durante o curso FJ-21 estudamos o MVC Push, através do SpringMVC e no FJ-26, estudamos o JSF e o MVC Push.”
o segundo MVC Push não seria MVC Pull ?
Adriano Almeida
03. jul, 2012
Oi Arthur, tem razão! Já acertei no post!
Obrigado.
Samuel
03. jul, 2012
Ter componentes ricos controlados via código java na minha opinião não é tão elegante(A exemplo criar tree no primefaces), hoje em dia diversos frameworks javascript possuem componentes extremamente ricos(Extjs, jquery ui, kendo ui), sem falar que nesse caso ficamos apenas dependendo do formato dos dados trafegados via cliente-servidor que pode ser json e, que, com isso a mudança de framework controlador fica relativamente mais fácil ‘bastando’ tratar os dados da forma correta.O que toca aqui é o tempo pra dominar a dada tecnologia de visão.Cada caso é um caso.
Ótimo post.
Rafael Rossignol
03. jul, 2012
Ótimo post, no meu mundo ideal não deveriamos ter que aprender Javascript, nem html, nem nada do genero.
Devia ser tudo uma coisa só, tudo java, no máaaximo uma linguagem de marcação para definir de maneira mais fácil a view.
Esse negocio de ter que usar javascript + html + json + jquery + struts + spring bean +java + groovy eventualmente
isso é uma loucura que deveira ter acabado faz muitos anos.
Fernando Franzini
03. jul, 2012
Parabéns pelo artigo, curto, objetivo e claro.
Hedley
03. jul, 2012
Post extremamente complicado.., pra mim, os dois têm vantagens em relação ao outro. Mas, analisando do ponto de vista de acoplamento, facilidade de manutenção e design(do todo), o MVC Push(Spring,VRaptor..) é mais adequado. Mas, a curva de aprendizado dele, pelo menos comigo, é bem maior que a do MVC Pull(JSF), pois este te abstrai MUITA coisa, o que é bom e ruim(como tudo na vida). JSF não é RESTful o que pode ser um problema, mas se você só pretende usar “Post”, isso não é problema. Até onde conheço, o JSF não é lá muito amigável para TDD, e isso sim, é um grande problema. Dizem que o JSF consome muita memória, tráfego de rede e tal, nunca fiz um benchmark pra medir isso, por isso não posso opinar.
Adriano Almeida
03. jul, 2012
Oi Hedley,
exato, é um assunto bem complicado mesmo. E como você disse, ambos os estilos de MVC possuem trade-offs, mas as diferenças são bem sutis.
Com relação ao framework, usando o JSF com CDI, você melhora demais a testabiilidade da sua aplicação no caso de testes de unidade.
E o JSF precisa manter o ViewState para nós, esse é um dos motivos para usarmos seus componentes. Esse ViewState pode ser guardado tanto no cliente quanto no servidor e você escolhe o que você vai onerar, consumir memória no caso de guardar no servidor ou requests mais pesados, no caso de guarda-la no cliente.
Mas como você disse, não é uma decisão fácil. Ambas as abordagens tem vantagens e desvantages. O mais importante é entende-las e estarmos preparados para tomar a decisão mais acertada na hora que tivermos que escolher um deles.
Abraço
Rafael Roque
03. jul, 2012
“Ótimo post, no meu mundo ideal não deveriamos ter que aprender Javascript, nem html, nem nada do genero”
@Rafael Rossignol,e quando vc precisar ter um controle mais “fino” sobre o que é gerado por baixo dos panos?
Eu uso e gosto de JSF,mas pra mim esse é um grande ponto negativo dos frameworks component-based.
Rafael Roque
03. jul, 2012
Adriano,parabéns pelo texto,muito sucinto e objetivo.
Mas,para fins didáticos será que não seria melhor ter exemplificado o JSF com uma tela de cadastro ao invés de listagem?
Digo isso pq é grande o numero de desenvolvedores que simplesmente não entendem que usando JSF vc não precisa mais ‘extrair’ os dados do request,já está tudo encapsulado no componente em si.
Adriano Almeida
03. jul, 2012
Oi Rafael Roque, tudo bom?
Pensei bastante nisso também enquanto escrevia o post, a ideia de mostrar a listagem é que ficava mais explícito o processo da View pegar os dados Managed Bean. Só isso mesmo, mas concordo contigo que não precisa mais extrair os dados do request.
Aliás, no Spring MVC também não! Acabei só o utilizando ali para também deixar explícito o processo de disponibilizar os dados para a View.
Como o objetivo não era mostrar o framework e sim o estilo de MVC, acabei preferindo esse caminho.
Abraço
Bob
03. jul, 2012
Adriano, parabéns pelo artigo!
Pelo que entendi, se eu quisesse trabalhar com um framework Action based, teria mais flexibilidade, por exemplo, de trocar a View (JSP) da minha aplicação por outra, pelo fato de existir este desacoplamento entre o @Controller, no caso do springMVC? Fato este que não ocorreria com uma arquitetura Component Based, no caso, JSF, já que para existir uma página JSF, tem de existir um MBean associado?
Comecei com a arq CB e hoje estou estudando e comparando com a arq AB. Depois deste artigo, clareou bem por aqui.
Obrigado.
Adriano Almeida
03. jul, 2012
Oi Bob, tudo bom?
Não só isso, mas como o acoplamento é menor entre a View e o @Controller, qualquer alteração que você faça lá com relação a mudança nos métodos dos seus @Controller, não impactará em nada nas views. No JSF isso já não acontece.
Abraço
Fuad Saud
03. jul, 2012
Eu já trabalhei um pouco com MVC e gostei bastante da estrutura. Mas me diz: esses componentes “ricos” conseguidos por meio do JSF, por exemplo, não poderia ser substituidos por JavaScript e AJAX? Não entendo muito, por isso to perguntando…
Adriano Almeida
03. jul, 2012
Oi Fuad, tudo certo?
Com relação a geração e o visual do componentes consegue sim, na verdade, os próprios componentes do JSF usam Javascript. O Primefaces, por exemplo, utiliza JQuery em seus componentes. O que você perde, é a possibilidade de invocar alguma regra no modelo que possa influir na geração do componente.
Abraço
Rafael Roque
03. jul, 2012
@Fuad Saud
Conseguir vc consegue,mas precisa de um conhecimento de médio a avançado em javascript,jquery etc.
A minha opinião é que a força do JSF é tbm a sua fraqueza:ao mesmo tempo que te abstrai muita coisa da geração das interfaces,também te deixa refém do que ele te oferece,tornando dificil uma customização mais ‘fina’.
nei
03. jul, 2012
Muito bom o post, parabéns !!!
Já havia “googlado” outras vezes sobre o assunto, e não tinha achado algo mais completo como esse post
Sei que é uma decisão arquitetural e até “subjetiva”, mas você poderia ter comentado sobre os pontos a serem considerados ao escolher uma tecnologia ou outra em um projeto que esteja começando, pois mesmo entendendo sobre as diferenças entre as duas tecnologias, não ficou claro em qual usar/escolher, justamente devido a essas diferenças sutis.
Obrigado
Reinaldo Vale
03. jul, 2012
Muito bom o post.
Já trabalhei muito com JSF. No início não entendia muito sobre o http, js, html etc. O JSF caiu como uma luva para as minhas necessidades, justamente por abstrair a forma que a web funciona.
Hoje, com um pouco mais de conhecimento, consigo ver várias desvantagens de abstrair o funcionamento da web. Para mim, abordagens Restful é o futuro da web.
Neste sentido eu pergunto… Por que diabos não temos na especificação JEE uma referência action based?
Mateus
12. jul, 2012
Ótimo post , eu já tava tendo uma ideia de como funcionava os dois tipos de frameworks, mas agora tenho tudo esclarecido. To afim de fazer o curso de arquitetura da Caelum, parece ser muito bom
Alexandre Simundi
12. jul, 2012
Muito bom o post!!
Trabalhei bastante tanto com SpringMVC quanto com JSF. Sei da diferença entre eles, mas confesso que não sabia que existia essa os nomes MVC Pull/Push.. muito bom!!
Minha única questão é sobre esse ponto:
“…o que inviabiliza, por exemplo, o uso de qualquer biblioteca de componentes do JSF com um framework como o Spring MVC…”
Se não me engano, a integração de JSF com Spring é feita justamente através de annotações “@Controller” nos ManagedBeans. Dessa forma, o ciclo de vida dos ManagedBeans é controlado pelo Spring, possibilidade a DI, etc..
Posso ter feito confusão.
Mais uma vez, parabéns!
Adriano Almeida
12. jul, 2012
Oi Alexandre, tudo bom?
O que acontece no caso que você falou, é que o Spring (não o SpringMVC), reaproveita a anotação @Controller, para indicar quem são os ManagedBeans para que ele possa fazer injeção de dependencias e controlar o escopo. No entanto, não há nenhuma relação com o SpringMVC, a não ser o fato de usar a anotação @Controller também.
Se você estiver usando o JSF, o ciclo de vida será o do JSF, o Spring nesse caso que você citou estará ali só para possibilitar para você os recursos do Spring Framework.
Deu para entender?
Abraço
Alexandre Simundi
12. jul, 2012
Saquei!
Obrigado pela explicação.
Abraço
Felipe Caparelli
12. jul, 2012
Este post tratou de forma sintática um assunto corriqueiro e polêmico para os javeiros. Mas o mais legal foram os comentários que agregaram demais na discussão e colocaram diversos outros pontos que não foram abordados.
Com relação a unificação das tecnologias, como citou o Rafael Rossignol, eu já tive essa visão, porém hoje em dia acho que da pra se trabalhar de forma coesa usando diversas técnicas e tecnologias… e no final das contas isso contribui e muito para a evolução da TI.
Parabéns Adriano! Ótima postagem…
o blog da Caelum está cada dia mais interessante e rico em diversidade de conteúdos! Continuem o bom trabalho!
Suporte
12. jul, 2012
No fim das contas, vc tem sempre que saber Java + javascrip + css + html!
thiago correia
13. jul, 2012
Muito bem explicado. Ótimo artigo
Diomar Rockenbach
20. jul, 2012
Olá,
Já sou desenvolvedor a mais de 4 anos, mas não de WEB. Trabalho com linguagem procedural. Comecei essa semana a trabalhar em um projeto no qual está sendo desenvolvido a partir de um framework próprio que está sendo feito baseado em JSF e spring. Não sei explicar ainda de forma muito clara como tudo funciona. Sei que usa o spring e o JSF, e realmente as view tem total dependência das classes controller e das classes entities que usam hibernate.
Gostei bastante do post, e já tenho muitas perguntas pra fazer na segunda para o desenvolvedor principal do projeto.
Parabéns.
Patrick Nascimento
24. jul, 2012
Estou fazendo o curso FJ26 aqui em Bsb e adorei o Post, muito instrutivo!
Adolfo Eloy
05. ago, 2012
Adriano, ótimo post.
Vejo que hoje em dia muitas pessoas falam do MVC sem ao menos conhecer tais variações (pull / push).
Acabei interessado neste artigo pois onde trabalho, participei do desenvolvimento de uma estrutura onde só trabalhavam com componentes da família JSF, e foi necessário utilizar códigos em JS para realizar requisições via AJAX apenas para recuperação de dados (em formato JSON).
Recebi uma crítica dizendo que isso “quebrou” o MVC. Na verdade como não tinha tempo p/ discutir o assunto, preferi pesquisar e entender por si só o fundamento da solução.
Com o que tenho pesquisado, cheguei a conclusão que não faz sentido dizer que a utilização do AJAX “quebrou” o MVC. (Até porque muitos componentes do próprio Richfaces utilizam AJAX).
A requisição AJAX assim como uma requisição síncrona irá ser tratada pelo Controlador, será direcionada para o ManagedBean correto que por sua vez utilizará o Modelo para validações e etc.
Gostaria de saber se poderia deixar sua opinião a respeito.
Thais
26. set, 2012
Antes de tudo, parabens pelo artigo! Muito legal!
Eu tenho bastante esperiencia com JSP e apenas um overview de JSF.
Para aprofundar meus conhecimentos, quis fazer uma peq app usando JSF, mas pra minha surpresa, comecei a me enrolar na separacao das camadas.
Alguem sabe de algum bom tutorial q me mostraria por ex, como com JSF acessar o banco e mostrar as informacoes na tela? Queria um q seguisse boas praticas, e queria referencia pra nao fazer errado, pois com JSP acho varios exemplos e ate livros q nao acho boas praticas, mas estes tenho nocao do que deve ser feito ou nao, e como para JSF nao tenho, nao gostaria de pegar qq coisa e aprender da forma errada…
Desde ja agradeco!
Rodrigo Marini
09. out, 2012
GWT na cabeça!
A maioria dos desenvolvedores Java gostam de escrever código Java… Gostam de Orientação a Objetos!
Perder tempo com JS, Components, Ajax, etc… Não vira!
Thiago Paredes
06. dez, 2012
Ótimo post !
Objetivo e esclarecedor. Parabéns Adriano.
Adriano Santos
18. dez, 2012
Ótimo artigo, objetivo!
Alexandre
03. jan, 2013
Adriano, uma dúvida constante para mim, é sobre que framework escolher para migrar uma aplicação que não utiliza nenhum deles, para eliminar scriptlets e implementar um framework MVC, o que você aconselha?
Adriano Almeida
03. jan, 2013
Oi Alexandre,
depende muito das características da aplicação. Sistemas, com diversas abas e telas com características de que devem manter estado (por exemplo, aquelas telas master/detail), eu muito provavelmente iria de JSF (component based).
Se não fosse o caso, eu tenderia a ir para uma abordagem component based. Qualquer framework moderno, aí vai mais é do gosto mesmo. Meus preferidos hoje em dia são o SpringMVC e o VRaptor.
Ok?
Abraço e qualquer coisa, posta aí.
Realidade
16. fev, 2013
Quem usa só JSF não é desenvolvedor web. Palavras de quem usava component-based no passado e achava que era desenvolvedor web.
Alessandro
03. abr, 2013
Post muito profissional e didático. Parabéns!
As contribuições nos comentários também foram fantásticas.
Vejam porque adotamos o Apache Wicket em nossa organização. Trabalho num lugar que existe há 40 anos, sempre lidando com processamento de dados, depois informática e agora Tecnologia da Informação. Passou-se por todas as tecnologias que vocês possam imaginar: desde Natural, passando por VB, até Oracle Forms. Estamos agora indo para o Java.
Um lugar antigo possui desenvolvedores antigos, mas tão bons de lógica quanto os mais novos. E eles viveram muito a época dos aplicativos cliente-servidor desktop (Delphi, VB, Windows Forms). Então, adotar o Wicket foi uma estratégia para recepcionar bem esse pessoal no Java. A ideia de eventos em componentes está presente no Wicket. Sim, abstrair o funcionamento do HTTP pode ser ruim, mas queremos produtividade e inserção de pessoas.
Mas, Adriano, para os casos em que serão desenvolvidos sites, portais, hotsites – mas casos que fogem do conceito puro de CMS (Plone/Zope, LifeRay, Joomla), publicação de conteúdo enfim?
Refiro a sites e portais que não são sistemas de informação com regras de negócio, mas que mesmo assim têm campos, formulários, exibição de dados oriundos de serviços expostos, aí sim, por sistemas/aplicações de negócio.
O MVC se aplica? Se sim, melhor seria os frameworks Action-bases?
Obrigado!
Alessandro