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.
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.
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!
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.
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
[quote]
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.[/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.
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. :lol:
[quote=victorwss]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.
:)[/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.
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.
No momento não surgiu necessidade de fazer-se isso. Mas caso venha a surgir, o Comet seria a saída.
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.
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]
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]
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.
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]
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]
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.
Para os amigos que estão iniciando em MVC para WEB, recomendo a apostila 21 da Caelum!
Gostei muito da forma como está sendo explicado o MVC nela. Porém sinto uma grande falta de explicações desse nível para MVC DESKTOP 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 :D) 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. 
Que nada mais é do que um Presentation Model: http://www.martinfowler.com/eaaDev/PresentationModel.html
aplicando essa filozifia como ficaria entao um programa web usando mvc?
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?
ORganizar o sistema em modulos de acordo com sua responsabilidade é bom, até então nada de MVC, apenas boas práticas. O que você espera alcançar implementando MVC na Web?
[quote=victorwss]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.
:)[/quote]
Bem interessante… mas imagino que esta arquitetura deva dar uma grande trabalheira com javascript…
[quote=thimor]aplicando essa filozifia como ficaria entao um programa web usando mvc?
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…)
[quote=thimor]aplicando essa filozifia como ficaria entao um programa web usando mvc?
[/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.