Dúvidas de MVC que sempre ouço por aí (E que também você ouça)

This message was edited 1 time. Last update was at 30/06/2009 19:49:07

Na minha opinião, pra implementar MVC (como foi concebido inicialmente) na Web o componente View deveria observar o model. Que hoje em dia dá até pra fazer usando Ajax reverso, mas quase ninguem faz porque poucas aplicações tem essa necessidade. Geralmente se chama de MVC diversas implementações que nada tem a ver com isso. Por isso surgiram os tails MVC2 ou Model 2 ou XPTO da vida. Mas isso é só a minha opinião, não sou o dono da verdade.

JWizard Membro desde: 18/02/2008 16:17:53 Mensagens: 2981 Offline

mochuara wrote: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.

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

PS: Não estou falando que a metodologia é um produto, estou me referindo ao auê que fazem sem saber o que é na verdade.

GUJ Master Membro desde: 07/06/2008 14:41:04 Mensagens: 1622 Offline

Quando ouvi falar de MVC pela primeira vez, em uma disciplina de estrutura de dados, achei aquela idéia muito legal.
A princípio não entendi precisamente como funciona esse bixo e achava realmente isso que o colega diz não ser:

MVC NAO é apresentacao/dominio/persistencia. Uma coisa é uma coisa, outra coisa é outra coisa. MVC é apenas uma das formas de se separar apresentacao de dominio.

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 pra cada View uma nova Controler deve ser concebida, 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.

GUJ Master Membro desde: 07/06/2008 14:41:04 Mensagens: 1622 Offline

Um dos "crimes" que mais tenho testemunhado é a mistureba de lógica de negócios em todas, TODAS as "camadas" do MVC.

GUJ Master Membro desde: 07/06/2008 14:41:04 Mensagens: 1622 Offline

A propósito, alguém poderia sugerir uma denominação pra que eu usasse no lugar de "camada" ?
Isso ta me deixando desconfortável, mas não consigo encontrar expressão melhor.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

Emerson Macedo wrote:Na minha opinião, pra implementar MVC (como foi concebido inicialmente) na Web o componente View deveria observar o model. Que hoje em dia dá até pra fazer usando Ajax reverso, mas quase ninguem faz porque poucas aplicações tem essa necessidade. Geralmente se chama de MVC diversas implementações que nada tem a ver com isso. Por isso surgiram os tails MVC2 ou Model 2 ou XPTO da vida. Mas isso é só a minha opinião, não sou o dono da verdade.

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.

Em MVC cada sigla representa um "componente", não uma camada. Se tratando de sistemas com telas o MVC fica quase todo na "camada" de apresentação, sendo o M (i.e. Model) uma ligação com a camada e aplicação/domínio. Tem algumas variações ai mas muitas vezes o que se faz é isso.

GUJ Master Membro desde: 07/06/2008 14:41:04 Mensagens: 1622 Offline

Emerson Macedo wrote: Se tratando de sistemas com telas o MVC fica quase todo na "camada" de apresentação, sendo o M (i.e. Model) uma ligação com a camada e aplicação/domínio. Tem algumas variações ai mas muitas vezes o que se faz é isso.

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.

O que acontece é que geralmente o pessoal vê o model como uma classe mas model é um componente (pode ser entendido como um subsistema) que poderia ser toda a camada de negócios. Como eu disse, a forma de implementar isso varia um pouco, não é muito exata. O importante é entender que MVC é um padrão para comunicação entre componentes e não para separação em camadas.

GUJ Master Membro desde: 07/06/2008 14:41:04 Mensagens: 1622 Offline

Emerson Macedo wrote:O que acontece é que geralmente o pessoal vê o model como uma classe mas model é um componente (pode ser entendido como um subsistema) que poderia ser toda a camada de negócios. Como eu disse, a forma de implementar isso varia um pouco, não é muito exata. O importante é entender que MVC é um padrão para comunicação entre componentes e não para separação em camadas.

Sim, exatamente!
Model não é uma classe, mas é todo O 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!

This message was edited 1 time. Last update was at 01/07/2009 21:29:37

Bem, quanto a repensar o MVC como eu tinha dito, já que ninguém perguntou, deixa eu colocar aqui.
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.

GUJ Master Membro desde: 04/06/2007 17:47:24 Mensagens: 1030 Offline

Afinal, Camada ou Componente, eis a questão?
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

The MVC architecture divides applications into three layers--model, view, and controller--and decouples their respective responsibilities. Each layer handles specific tasks and has specific responsibilities to the other areas.

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.

This message was edited 2 times. Last update was at 02/07/2009 07:05:09

djemacao wrote:Agora, o que mais vejo é o pessoal falando da tal camada=tier, que é também outra história.

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.

editado: 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 artigo no site da msdn.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

victorwss wrote:Bem, quanto a repensar o MVC como eu tinha dito, já que ninguém perguntou, deixa eu colocar aqui.
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.

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.

mochuara wrote: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.

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.

mochuara wrote: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.

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

mochuara wrote: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.

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.

Notícias, artigos e o maior fórum brasileiro sobre Java