Entenda os MVCs e os frameworks Action e Component Based

É 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?

48 Comentários

  1. Arthur Gregorio 03/07/2012 at 10:53 #

    ó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 ?

  2. Adriano Almeida 03/07/2012 at 10:57 #

    Oi Arthur, tem razão! Já acertei no post!

    Obrigado.

  3. Samuel 03/07/2012 at 11:11 #

    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.

  4. Rafael Rossignol 03/07/2012 at 11:33 #

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

  5. Fernando Franzini 03/07/2012 at 12:12 #

    Parabéns pelo artigo, curto, objetivo e claro.

  6. Hedley 03/07/2012 at 12:33 #

    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.

  7. Adriano Almeida 03/07/2012 at 12:45 #

    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

  8. Rafael Roque 03/07/2012 at 14:09 #

    “Ó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.

  9. Rafael Roque 03/07/2012 at 14:14 #

    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.

  10. Adriano Almeida 03/07/2012 at 14:27 #

    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

  11. Bob 03/07/2012 at 15:39 #

    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.

  12. Adriano Almeida 03/07/2012 at 16:00 #

    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

  13. Fuad Saud 03/07/2012 at 17:00 #

    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…

  14. Adriano Almeida 03/07/2012 at 17:18 #

    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

  15. Rafael Roque 03/07/2012 at 20:06 #

    @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’.

  16. nei 03/07/2012 at 22:14 #

    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

  17. Reinaldo Vale 03/07/2012 at 22:44 #

    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?

  18. Mateus 12/07/2012 at 11:48 #

    Ó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

  19. Alexandre Simundi 12/07/2012 at 12:32 #

    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!

  20. Adriano Almeida 12/07/2012 at 12:40 #

    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

  21. Alexandre Simundi 12/07/2012 at 13:03 #

    Saquei!

    Obrigado pela explicação. 😉

    Abraço

  22. Felipe Caparelli 12/07/2012 at 15:08 #

    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!

  23. Suporte 12/07/2012 at 15:54 #

    No fim das contas, vc tem sempre que saber Java + javascrip + css + html!

  24. thiago correia 13/07/2012 at 10:59 #

    Muito bem explicado. Ótimo artigo

  25. Diomar Rockenbach 20/07/2012 at 23:16 #

    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.

  26. Patrick Nascimento 24/07/2012 at 02:37 #

    Estou fazendo o curso FJ26 aqui em Bsb e adorei o Post, muito instrutivo!

  27. Adolfo Eloy 05/08/2012 at 18:19 #

    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.

  28. Thais 26/09/2012 at 01:17 #

    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!

  29. Rodrigo Marini 09/10/2012 at 11:37 #

    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!

  30. Thiago Paredes 06/12/2012 at 16:42 #

    Ótimo post !

    Objetivo e esclarecedor. Parabéns Adriano.

  31. Adriano Santos 18/12/2012 at 22:00 #

    Ótimo artigo, objetivo!

  32. Alexandre 03/01/2013 at 11:35 #

    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?

  33. Adriano Almeida 03/01/2013 at 11:49 #

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

  34. Realidade 16/02/2013 at 23:05 #

    Quem usa só JSF não é desenvolvedor web. Palavras de quem usava component-based no passado e achava que era desenvolvedor web.

  35. Alessandro 03/04/2013 at 22:37 #

    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

  36. masumcse 26/10/2014 at 05:40 #

    which one is good for enterise solution ?

    Component based framework / MVC PULL /JSF

    Pros :

    cons :
    ===============================================================

    Component based framework / MVC PUSH /Spring /Struts2

    Pros :

    cons :
    ===============================================================

    any one pls convert it to english ?

  37. masumcse 26/10/2014 at 05:41 #

    which one is good for enterise solution (like financial based large form based app ) ?
    why ?

  38. Marcelo Oliveira 21/11/2014 at 11:53 #

    Poxa depois de muito andar(navegar) achei um post realmente esclarecedor sobre o assunto component based vs action based – atualmente desenvolvo com JSF(e estou insatisfeito) e estou convencido como o colega citou acima, o futuro é restfull, desacoplamento geral entre front e back.

    Parabéns Adriano Almeida pelo ótimo post!

  39. Hermes Waldemarin 10/04/2015 at 07:22 #

    Um ponto extremamente importante da Orientação a objetos é manter o acoplamento baixo e a coesão alta. Com isso em mente acredito eu que manter o frontend desacoplado do backend utilizando rest por exemplo com algo como angularjs no front por exemplo, me parece uma boa abordagem. Isso faz com que as evoluções ocorram de forma mais natural.
    Outro ponto que tenho refletido ultimamente é que os devs java acabam curtindo e se dedicando muito aos códigos backend e geralmente não curtem html, css e os paranaues para deixar a view bonitinha, bem feita, pensando em ux, e várias outras tecnologias e assuntos relacionados a frontend.
    Por isso nesse caso sou a favor de sempre que possível tem um frontend developer focado na view e os backends felizes fazendo o que gostam. Agora se não tem jeito de separar os papeis devemos usar o que é mais fácil desenvolver e que fique com uma qualidade aceitável em termos visuais e código, porém o que está sendo sacrificado será sempre a capacidade de adaptação do produto a novas tecnologias que aparecerem impossibilitando em varios momentos o refactoring.
    #meupontodevista

  40. Welder 24/11/2016 at 13:55 #

    Muito bom esse artigo!!
    Explica de forma clara a lógica por trás destas arquiteturas…

    Parabéns!!

Deixe uma resposta