http://www.guj.com.br/posts/list/12.java JForum - http://www.jforum.net
De tempos em tempos, sempre aparece alguém perguntando alguma coisa sobre MVC. Resolvi então fazer um post sobre muitas delas que já ouvi ( http://www.objectzilla.com.br/2009/06/29/mvc-supostas-perguntas-frequentes/ ).

Entre as respostas digo que MVC não são camadas, que Controller é intimamente ligada à View, que Model deve estar desacoplada ao Model e outros conceitos mais comuns. Lógico que não dá pra cobrir tudo, por isso pensei: e vocês? Já tiveram uma sensação sobre MVC que não entrava na cabeça? Ou então: já ouviram alguém falando sobre MVC que achou errado?

]]> http://www.guj.com.br/prepost/131022/705781/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/705781/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT O MVC da Web é diferente do MVC do Desktop?
R. Sim, existem duas diferenças: 1) um Controller de Desktop recebe eventos de clique do mouse, de teclado, de botões e outros componentes; um Controller de Web recebe exclusivamente eventos de submissão. Consequência: aplicações Desktop são orientadas a eventos, enquanto aplicações Web, orientadas a fluxos. Tudo que uma aplicação web entende é uma ?stringona? com os dados de um suposto formulário (não dá pra saber se o cliente é humano ou que viu a interface gráfica) e que precisa devolver uma nova ?stringona? para o cliente que, supostamente, renderiza para algum desenho gráfico. A aplicação Desktop sabe exatamente os eventos recebidos e pode agir diferentemente para cada um deles. 2) A View de Desktop mantém sincronia constante do Model (através do pattern Observer), qualquer alteração que o usuário fizer no model através de um painel, será refletida imediatamente em outros painéis que, porventura, estejam visualizando o mesmo Model. Na Web, não existe nada disso, a partir do momento em que o usuário está diante de uma tela, essa representação do Model estará desconectada do Model real e o usuário não saberá quanto (e se) o Model mudou. O único momento de mudança é quando o usuário aperta F5, mas isso implica num evento consciente do usuário, não numa coisa automática, como as aplicações Desktop de qualidade fazem.

[/quote]

Pra mim está aqui a raiz do problema. O cara le que struts/jsf/sei-la-o-que-mais é um framework mvc, aí ele vai dar uma estudada em o que é mvc. Evidentemente essa "estudada" é dar uma olhada meio por cima em alguns blogs e artigos.

Esses blogs e artigos definem o que é mvc para desktop. O programador se confunde todo e no meio do caos que ele está aparece a frase, divida sua aplicacao em apresentacao, negocio e persistencia. E pronto, ta feita a confusao.

O conhecimento de um programador é como o bom senso, ninguem acha que precisa ter mais do que tem.

]]> http://www.guj.com.br/prepost/131022/706091/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706091/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Também concordo com o YvGa, mas acho que o problema é bem maior. Há muita gente por aí espalhando e postando coisas que dizem ser MVC mas são apenas uma versão distorcida e degenerada dele, tal como ocorreu com o cara que me "ensinou" isso. Esse tipo de coisa apenas causa confusão e desinformação e cria o efeito que vejo atualmente de "cada um tem uma definição diferente do que é o MVC".
Particularmente, uma coisa que odeio são os decoradores de framework que "aprendem a mexer" com struts, spring, JSF ou RoR, e que adoram abusar da sigla MVC como buzzword e a utilizá-la esbanjadoradamente mais por questão de marketing do que pelo conceito, mesmo sem saber direito o que a sigla significa. Dizem religiosamente que o seu framework preferido é a única forma correta existente de se usar o padrão MVC, e consideram uma heresia grave quem ousar discordar deles.

Eu particularmente, nunca achei uma implementação que julgasse ser plenamente correta e limpa do padrão MVC, incluindo as que eu mesmo fiz. Mas uma coisa que sei é que embora nunca tenha visto uma implementação plenamente correta e limpa, sei que existem diversas formas possíveis diferentes plenamente corretas e limpas. Incluindo algumas que não são nem o chamado MVC web e nem o chamado MVC desktop (alguém já parou para pensar que o MVC web do jeito que costuma ser definido é relativamente limitado em relação ao ajax? Eu já!)]]> http://www.guj.com.br/prepost/131022/706153/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706153/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT http://www.guj.com.br/prepost/131022/706162/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706162/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Exato! E é aí que o tão chamado "modelo web MVC" começa a quebrar. Logicamente, para dar um jeito nisso a saída preferida do pessoal costuma ser a famosa gambiarra. Mas, curiosamente muitos se preocupam em definir o MVC, mas poucos se preocupam em redefinir o MVC.]]> http://www.guj.com.br/prepost/131022/706170/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706170/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT http://www.guj.com.br/prepost/131022/706212/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706212/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
flws]]> http://www.guj.com.br/prepost/131022/706280/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706280/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT http://www.guj.com.br/prepost/131022/706294/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706294/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Web 2.0 é uma característica de aplicações web que tem caráter mais social. Pouco tem a ver com a tecnologia utilizada.

Talvez você esteja se referindo a AJAX. E nesse caso, pra uma aplicação extremamente ajaxificada, a arquitetura não é muito diferente de um desktop que "puxa coisas" do servidor: você tem uma aplicação Javascript que roda no cliente, e outra aplicação Java/ASP/PHP/Rails que roda no servidor. São duas aplicações onde cada uma tem seu MVC porque, como havia dito: não existe MVC distribuído. E no caso da aplicação servidor, ele exclusivamente recebe eventos de submissão, pois não dá pra saber se a origem é de um componente Ajax ou não.

Fui claro?]]> http://www.guj.com.br/prepost/131022/706326/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706326/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Padrões são como receitas de bolo incompletas. Não é porque, ao fazê-lo, removi um ingrediente ou pus outro, que deixei de fazer um bolo.

No MVC original, só existe a noção de eventos. Se ela vai ser implementada com Observer ou alguma outra coisa, isso não importa.

E discordo que na web não exista MVC, ela existe sim.
]]> http://www.guj.com.br/prepost/131022/706338/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706338/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT P. O Controller serve para controlar o sistema?
R. Não, o nome controller é que é confuso, e remete a alguns programadores o ?objeto deus? (God Object) ou o ?objeto bolha-assassina? (Blob Object). Porém, objetos deuses são anti-patterns, ou seja, soluções aparentemente ideiais para problemas recorrentes que causam mais problemas ainda. Quando vier à sua cabeça ?Controller?, pense-o como ?Input Controller? (controlador de entrada), e este ?coiso? deve fazer, estritamente, as seguintes atividades:
- ouve eventos;
- obtém os parâmetros de entrada desejados da View;
- obtém do Model um domínio (invariavelmente, este está num meio persistente);
- chama um método do domínio;
- escolhe a view a ser renderizada, fazendo ?bind? de algum domínio do Model.
Não raro, programadores pouco experientes colocam, no ?Controller?, lógicas de negócio ou tranformações de objeto para a view. Não é isso, remova esses códigos e ponham nos seus devidos lugares.
[/quote]

Onde você coloca o negocio nesse caso? Teriam Business Objects? Ou o negocio e a persistencias sao o model? O model não seria apenas POJOS?]]> http://www.guj.com.br/prepost/131022/706342/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706342/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
flws[/quote]

Essas eram as tecnologias que estavam na crista da onda na era da Web 2.0 mas eu percebo que há muito descontentamento com elas agora. Minha impressão é que apesar de serem coisas diferentes, elas compartilham algumas características sobre como frameworks e middlewares, enfim, plataformas são empurrados para o consumo geral como se fossem produtos ao invés de serviços.]]> http://www.guj.com.br/prepost/131022/706345/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706345/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT Padrões são como receitas de bolo incompletas. Não é porque, ao fazê-lo, removi um ingrediente ou pus outro, que deixei de fazer um bolo.

No MVC original, só existe a noção de eventos. Se ela vai ser implementada com Observer ou alguma outra coisa, isso não importa.

E discordo que na web não exista MVC, ela existe sim.
[/quote]

Sim, existe porque resolveram dar o mesmo nome a padroes diferentes. Assim como uma torta é diferente de um bolo, embora ambos tenham a mesma funcao.]]> http://www.guj.com.br/prepost/131022/706385/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706385/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Entendi, realmente parece mesmo, não havia pensado nisto.

Valeu!

flws
]]> http://www.guj.com.br/prepost/131022/706408/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706408/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT Onde você coloca o negocio nesse caso? Teriam Business Objects? Ou o negocio e a persistencias sao o model? O model não seria apenas POJOS?[/quote]

Nao, model nao sao apenas pojos, model eh tudo o que nao eh view. Services, facades, factories, repositorios, arquivos de configuracao, datasources, database, tudo é model.

Controller eh o que a view usa para modificar o modelo. No caso da web eles sao responsaveis tambem por encontrar a view a mostrada ao usuario, em desktop nem isso.

MVC NAO é apresentacao/dominio/persistencia. Uma coisa é uma coisa, outra coisa é outra coisa. MVC é apenas uma das formas de se separar apresentacao de dominio.]]> http://www.guj.com.br/prepost/131022/706471/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706471/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT http://www.guj.com.br/prepost/131022/706476/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706476/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
É a mesma coisa que está acontecendo com Scrum hoje, gerentes que tiram o produto da caixinha, começam a usar, e acham ruim pq não tá dando certo. Ningúem lê o fucking manual pra saber como usar, ou mesmo pra saber pra quê serve ou se precisam de verdade, acabam levando supositório achando que tá comprando aspirina.

[size=9]PS: Não estou falando que a metodologia é um produto, estou me referindo ao auê que fazem sem saber o que é na verdade.[/size]]]> http://www.guj.com.br/prepost/131022/706493/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706493/duvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT A princípio não entendi precisamente como funciona esse bixo e achava realmente isso que o colega diz não ser:
[quote]
MVC NAO é apresentacao/dominio/persistencia. Uma coisa é uma coisa, outra coisa é outra coisa. MVC é apenas uma das formas de se separar apresentacao de dominio.
[/quote]

Por um tempo permaneci na ignorância achando que era isso, talvez por não ter, na época, com quem conversar sobre isso (não participava do GUJ, programava em C++) e ficava feliz fazendo meus God Objects dizendo "to usando MVC".
Felizmente depois de um tempo refleti bastante e fui contestando aquilo que eu jugava saber sobre MVC.
Após ler bastante e principalmente quando comecei a trabalhar com Java meu contato com patterns cresceu bastante e continuo contestado a utilização de cada um deles, como acredito que deva ser feito por todos (principalmente arquitetos de sistema, ouviram? hehehehe).

Hoje consigo definir um modelo MVC muito mais fiel aquilo que ele se propõe, acredito, e não aquela visão distorcida que tive, por ter aprendido errado num primeiro momento.

Certa vez estava refletindo sobre a dependência da view com a controler e cheguei a conclusão de que [u]pra cada View uma nova Controler deve ser concebida[/u], uma vez que, como já citado anteriormente, essas duas "camadas" estão intimamente ligadas.
Conclui então que a "camada" model é composta por todo o "core" do projeto, onde a lógica de negócios estã implementada, junto a persitência e outras cocitas e pode(deve) ser organizado em "subcamadas" definidas.

Já vi muitos projetos que dizem implementar MVC com essas responsabilidades todas misturadas, inclusive comentendo heresias que prefiro não citar por aqui, o que me levou a pensar a respeito daquele projeto: "mvc uma ova!". Entre outros crimes hehehe de arquitetura.

Espero ter me espressado corretamente, qualquer coisa estou aberto a discuções e por favor, caso discordem eu peço que dêem sua opinião, algo que aprendi muito nos últimos anos foi a ouvir.]]> http://www.guj.com.br/prepost/131022/706631/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706631/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT http://www.guj.com.br/prepost/131022/706636/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706636/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT Isso ta me deixando desconfortável, mas não consigo encontrar expressão melhor.]]> http://www.guj.com.br/prepost/131022/706639/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706639/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Acontece que para a view observar o model (que significa basicamente a capacidade do servidor invocar o cliente sobre alguma atualizacao) vai contra de uma das premissas basicas do modelo Web que é o cliente iniciar a comunicação.]]> http://www.guj.com.br/prepost/131022/706649/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706649/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT http://www.guj.com.br/prepost/131022/706650/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706650/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Emerson, será que você poderia falar mais sobre essas afirmações?
Pelo que entendi, você disse que o model é um componente que conversa com a camada de negócios, correto?
Por favor, fale mais.
Obrigado.]]> http://www.guj.com.br/prepost/131022/706685/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706685/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT http://www.guj.com.br/prepost/131022/706759/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706759/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Sim, exatamente!
Model não é uma classe, mas é todo [b][i][u]O[/u][/i][/b] sistema, onde a regra de negócios está implementada, independente da interface que for criada, o comportamento do model será precisamente o mesmo!
Muito obrigado pela resposta, fico contente em ver que estou indo pelo caminho certo.

Abraços!]]> http://www.guj.com.br/prepost/131022/706817/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/706817/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT Tenho um projeto em andamento, que inclusive apresentei em uma das disciplinas do meu mestrado, que é assim:

View = HTML estática misturado com trechos de javascript para fazer no lado do cliente o que o JSP normalmente faz no lado do servidor. A HTML não corresponde a uma página completa, apenas a uma div.
Controller = javascript + JQuery.
Model = métodos de negócio no servidor expostos por uma interface REST.

A comunicação entre a controller e a model é feita puramente com Ajax e JSON. A página principal NUNCA é recarregada. Ao invés disso, a controller (escrita em javascript) baixa o HTML das páginas que ele acessa, interpreta o javascript delas e insere a div resultante na árvore DOM. Páginas com HTML já baixadas são mantidas em cache e o javascript delas é reavaliado quando pertinente.

Resultado: No servidor eu me preocupo apenas com regras de negócio. Quem se preocupa com apresentação é o browser e o servidor não quer nem saber disso, o máximo que ele fornece em relação a isso é conteúdo estático. O resultado por enquanto tem sido excelente em todos os sentidos.

Então, isso definitivamente não é o MVC tradicional e nem o MVC web. O que eu fiz foi reinventar/repensar o MVC.
]]> http://www.guj.com.br/prepost/131022/707107/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/707107/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT Não, a tradução em Java é layer, camada. Pra mim, chamar de componente é errôneo. Componente pra mim e muitos e' outra coisa, desculpa gente. Eu acho que o que mais confunde são os que leem o danado do White paper original, criado para SmallTalk e saem dizendo ai bom, sei lá o que entendem. Ele foi feito numa época que, bem, não era Web.
Em Java:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html
[quote]
The MVC architecture divides applications into [b]three layers[/b]--model, view, and controller--and decouples their respective responsibilities. Each layer handles specific tasks and has specific responsibilities to the other areas.[/quote]

Bom, se mudarem isso, mudo minha opinião.
Agora, o que mais vejo é o pessoal falando da tal camada=tier, que é também outra história.

]]> http://www.guj.com.br/prepost/131022/707129/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/707129/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT o acrônimo tier está associado a uma camada física, no qual estabelece uma separação de preocupação, sendo esta vista como um componente exposto em um ambiente distribuído, como na integração com sistemas esb, soa, jms, etc.

[b]editado[/b]: interessante além do MVP, surgiu já faz um tempo o MVVM, onde é mais uma jogada que se beneficia do padrão command para disparar eventos. Segue abaixo exemplo de uso no [url=http://msdn.microsoft.com/en-us/magazine/dd419663.aspx]artigo no site da msdn[/url].

]]> http://www.guj.com.br/prepost/131022/707150/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/707150/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT Tenho um projeto em andamento, que inclusive apresentei em uma das disciplinas do meu mestrado, que é assim:

View = HTML estática misturado com trechos de javascript para fazer no lado do cliente o que o JSP normalmente faz no lado do servidor. A HTML não corresponde a uma página completa, apenas a uma div.
Controller = javascript + JQuery.
Model = métodos de negócio no servidor expostos por uma interface REST.

A comunicação entre a controller e a model é feita puramente com Ajax e JSON. A página principal NUNCA é recarregada. Ao invés disso, a controller (escrita em javascript) baixa o HTML das páginas que ele acessa, interpreta o javascript delas e insere a div resultante na árvore DOM. Páginas com HTML já baixadas são mantidas em cache e o javascript delas é reavaliado quando pertinente.

Resultado: No servidor eu me preocupo apenas com regras de negócio. Quem se preocupa com apresentação é o browser e o servidor não quer nem saber disso, o máximo que ele fornece em relação a isso é conteúdo estático. O resultado por enquanto tem sido excelente em todos os sentidos.

Então, isso definitivamente não é o MVC tradicional e nem o MVC web. O que eu fiz foi reinventar/repensar o MVC.
[/quote]

Me parece que o seu caso não é MVC porque o que você chama de model (a interface REST) conhece tamvém o controler e a view, além das regras de negócio.

Do ponto de vista da interação MVC não melhorou muito também, ja que o model continua impossibilitado de notificar os componentes que foram deslocados para o cliente sobre mudanças nos seus dados.

Do ponto de vista da experiência do usuário, apesar de continuar aproveitando a penetreção e facilidade de acesso do browser existe uma degradação na experiéncia geral. Considere a dificuldade para bookmark uma tela, ou botão voltar não funcionar como se espera no browser.]]> http://www.guj.com.br/prepost/131022/707283/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/707283/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Negativo. O único objetivo do REST é expor a interface de alguma forma que seja acessível ao javascript ou a qualquer outra coisa que nele se conecte. Ele desconhece a view e a controller por completo, uma vez que só retorna JSON e este JSON contém apenas dados do negócio, nada de nomes de div ou qualquer coisa. A ideia aqui é possibilitar uma integração fácil com outros sites e o uso fácil em clientes swing, J2ME ou outra coisa. Absolutamente zero de javascript e HTML aqui.

[quote=mochuara]Do ponto de vista da interação MVC não melhorou muito também, ja que o model continua impossibilitado de notificar os componentes que foram deslocados para o cliente sobre mudanças nos seus dados.[/quote]

No momento não surgiu necessidade de fazer-se isso. Mas caso venha a surgir, o Comet seria a saída.

[quote=mochuara]Do ponto de vista da experiência do usuário, apesar de continuar aproveitando a penetreção e facilidade de acesso do browser existe uma degradação na experiéncia geral. Considere a dificuldade para bookmark uma tela, ou botão voltar não funcionar como se espera no browser.[/quote]

Não vejo nenhuma "degradação" nisso. Se você se refere ao bookmark ou ao botão voltar como degradação, basicamente o que existe (embora ainda esteja incompleto) é uma área onde uma URL direta é visível. Se você abrir uma nova aba ou uma nova janela com essa URL, ele abre naquele ponto.]]> http://www.guj.com.br/prepost/131022/707331/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/707331/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Negativo. O único objetivo do REST é expor a interface de alguma forma que seja acessível ao javascript ou a qualquer outra coisa que nele se conecte. Ele desconhece a view e a controller por completo, uma vez que só retorna JSON e este JSON contém apenas dados do negócio, nada de nomes de div ou qualquer coisa. A ideia aqui é possibilitar uma integração fácil com outros sites e o uso fácil em clientes swing, J2ME ou outra coisa. Absolutamente zero de javascript e HTML aqui.
[/quote]

Na verdade eu me expressei errado. É justamente o contrário, o model é muito genérico para a interação MVC, isto porque cada aplicação swing, j2me, e provavelmente cada aba do navegador corresponde a um VC e todos compartilham do mesmo M.

Lembre-se que o model não é necessariamente o core da aplicação, ele modela como é a interação no MVC.

[quote=victorwss]
[quote=mochuara]Do ponto de vista da interação MVC não melhorou muito também, ja que o model continua impossibilitado de notificar os componentes que foram deslocados para o cliente sobre mudanças nos seus dados.[/quote]

No momento não surgiu necessidade de fazer-se isso. Mas caso venha a surgir, o Comet seria a saída.[/quote]

Mas para ilustrar o que seria MVC essa questão é fundamental IMO.

[quote=victorwss]
[quote=mochuara]Do ponto de vista da experiência do usuário, apesar de continuar aproveitando a penetreção e facilidade de acesso do browser existe uma degradação na experiéncia geral. Considere a dificuldade para bookmark uma tela, ou botão voltar não funcionar como se espera no browser.[/quote]

Não vejo nenhuma "degradação" nisso. Se você se refere ao bookmark ou ao botão voltar como degradação, basicamente o que existe (embora ainda esteja incompleto) é uma área onde uma URL direta é visível. Se você abrir uma nova aba ou uma nova janela com essa URL, ele abre naquele ponto.[/quote]

Claro que com o uso de frameworks adequados é possível resolver essas questões facilmente, mas talvez esteja faltando no seu MVC definir um model para rodar no cliente e que fizesse por exemplo, polling das informações do webservice. Esse model que ficaria no cliente seria capaz de notificar as camadas superiores. Mas é importante notar que nesse esquema o MVc é novamente local, como se fosse uma aplicação desktop, mas rodando no browser.]]> http://www.guj.com.br/prepost/131022/707567/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/707567/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT
Negativo. O único objetivo do REST é expor a interface de alguma forma que seja acessível ao javascript ou a qualquer outra coisa que nele se conecte. Ele desconhece a view e a controller por completo, uma vez que só retorna JSON e este JSON contém apenas dados do negócio, nada de nomes de div ou qualquer coisa. A ideia aqui é possibilitar uma integração fácil com outros sites e o uso fácil em clientes swing, J2ME ou outra coisa. Absolutamente zero de javascript e HTML aqui.
[/quote]

Na verdade eu me expressei errado. É justamente o contrário, o model é muito genérico para a interação MVC, isto porque cada aplicação swing, j2me, e provavelmente cada aba do navegador corresponde a um VC e todos compartilham do mesmo M.

Lembre-se que o model não é necessariamente o core da aplicação, ele modela como é a interação no MVC.

[quote=victorwss]
[quote=mochuara]Do ponto de vista da interação MVC não melhorou muito também, ja que o model continua impossibilitado de notificar os componentes que foram deslocados para o cliente sobre mudanças nos seus dados.[/quote]

No momento não surgiu necessidade de fazer-se isso. Mas caso venha a surgir, o Comet seria a saída.[/quote]

Mas para ilustrar o que seria MVC essa questão é fundamental IMO.

[quote=victorwss]
[quote=mochuara]Do ponto de vista da experiência do usuário, apesar de continuar aproveitando a penetreção e facilidade de acesso do browser existe uma degradação na experiéncia geral. Considere a dificuldade para bookmark uma tela, ou botão voltar não funcionar como se espera no browser.[/quote]

Não vejo nenhuma "degradação" nisso. Se você se refere ao bookmark ou ao botão voltar como degradação, basicamente o que existe (embora ainda esteja incompleto) é uma área onde uma URL direta é visível. Se você abrir uma nova aba ou uma nova janela com essa URL, ele abre naquele ponto.[/quote]

Claro que com o uso de frameworks adequados é possível resolver essas questões facilmente, mas talvez esteja faltando no seu MVC definir um model para rodar no cliente e que fizesse por exemplo, polling das informações do webservice. Esse model que ficaria no cliente seria capaz de notificar as camadas superiores. Mas é importante notar que nesse esquema o MVc é novamente local, como se fosse uma aplicação desktop, mas rodando no browser.[/quote]

Ou seja, você está falando em transformar o model em um stub para o servidor?
Se for isso, sim é uma boa ideia. Eu estava bolando um negócio para fazer isso mas com uma outra finalidade completamente diferente. O seu post me deu a ideia de juntar as duas coisas. ]]> http://www.guj.com.br/prepost/131022/707588/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/707588/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT Gostei muito da forma como está sendo explicado o MVC nela. Porém sinto uma grande falta de explicações desse nível para [u]MVC DESKTOP[/u] e seu uso nas diversas formas diferentes de implementar (Observer ou Interfaces Listener's). [color=blue]E vou além:[/color] Acredito que pela falta de exemplos simples e claros de implementação - código de coisas simples como: Um cadastro, uma calculadora, um relógio, um termômetro - grande parte das pessoas acabam "entrando em conflito com a teoria", aprendendo errado e misturando tudo imaginando estar aprendendo MVC certo. Simplicidade com exemplos práticos, na minha opinião, resolve grande parte dos problemas que os companheiros javeiros INICIANTES (Atenção: INICIANTES como eu mesmo ) estão encontrando. Só a teoria por sí só deixa dúúúvidas sem esclarecimentos na hora de implementar.

Abraço a todos, parabéns Leonardo, lindo o tópico. ]]> http://www.guj.com.br/prepost/131022/709189/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/709189/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT [b]editado[/b]: interessante além do MVP, surgiu já faz um tempo o MVVM, onde é mais uma jogada que se beneficia do padrão command para disparar eventos. Segue abaixo exemplo de uso no [url=http://msdn.microsoft.com/en-us/magazine/dd419663.aspx]artigo no site da msdn[/url].
[/quote]

Que nada mais é do que um Presentation Model: http://www.martinfowler.com/eaaDev/PresentationModel.html]]> http://www.guj.com.br/prepost/131022/709416/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/709416/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT

cadastroProduto.jsp ---> ProdutoBean.java ---> ProdutoBO.java (Regras de negocio) ---> ProdutoDAO.java (Persistencia) ---> Produto.java

(.........VIEW............) --- (......CONTROLLER.....) --- (...........................................................MODELO.........................................................)

Como voce disse que o controller nao tem negocio deve ser colocada uma camada para aplicar as regras de negocio? ou pode-se colocar tudo na persistencia?]]> http://www.guj.com.br/prepost/131022/711118/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/711118/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT ]]> http://www.guj.com.br/prepost/131022/711133/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/711133/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT Tenho um projeto em andamento, que inclusive apresentei em uma das disciplinas do meu mestrado, que é assim:

View = HTML estática misturado com trechos de javascript para fazer no lado do cliente o que o JSP normalmente faz no lado do servidor. A HTML não corresponde a uma página completa, apenas a uma div.
Controller = javascript + JQuery.
Model = métodos de negócio no servidor expostos por uma interface REST.

A comunicação entre a controller e a model é feita puramente com Ajax e JSON. A página principal NUNCA é recarregada. Ao invés disso, a controller (escrita em javascript) baixa o HTML das páginas que ele acessa, interpreta o javascript delas e insere a div resultante na árvore DOM. Páginas com HTML já baixadas são mantidas em cache e o javascript delas é reavaliado quando pertinente.

Resultado: No servidor eu me preocupo apenas com regras de negócio. Quem se preocupa com apresentação é o browser e o servidor não quer nem saber disso, o máximo que ele fornece em relação a isso é conteúdo estático. O resultado por enquanto tem sido excelente em todos os sentidos.

Então, isso definitivamente não é o MVC tradicional e nem o MVC web. O que eu fiz foi reinventar/repensar o MVC.
[/quote]

Bem interessante... mas imagino que esta arquitetura deva dar uma grande trabalheira com javascript...]]> http://www.guj.com.br/prepost/131022/711141/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/711141/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT

cadastroProduto.jsp ---> ProdutoBean.java ---> ProdutoBO.java (Regras de negocio) ---> ProdutoDAO.java (Persistencia) ---> Produto.java

(.........VIEW............) --- (......CONTROLLER.....) --- (...........................................................MODELO.........................................................)

Como voce disse que o controller nao tem negocio deve ser colocada uma camada para aplicar as regras de negocio? ou pode-se colocar tudo na persistencia?[/quote]

cadastroProduto.jsp ---> FacesServlet ---> ProdutoBean.java --> ProdutoBO.java (Regras de negocio) --> ProdutoDAO.java --> Produto.java --> BD

(.......VIEW....) (......CONTROLLER.....) --- (..................................................................MODELO........................................................................)]]> http://www.guj.com.br/prepost/131022/711214/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/711214/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT [/quote]

Oi,

Antes de continuar alguma leitura recomendada:
http://fragmental.com.br/wiki/index.php/Evitando_VOs_e_BOs
http://fragmental.com.br/wiki/index.php/MVC_e_Camadas
http://fragmental.com.br/wiki/index.php/Fantoches
http://fragmental.com.br/wiki/index.php/Arquitetura_de_Camadas_em_Java_EE

E se você procurar no GUJ por "Camada de Negócios" vai encontrar algumas centenas de tópicos.]]> http://www.guj.com.br/prepost/131022/711222/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca http://www.guj.com.br/prepost/131022/711222/reduvidas-de-mvc-que-sempre-ouco-por-ai-e-que-tambem-voce-ouca GMT