Perguntas sobre MVC Desktop! Existe solução? (+ MVP,MVC WEB,Observer e Exception's)

This message was edited 1 time. Last update was at 18/10/2009 20:49:23

Olá André Fonseca e 71C4700, muitíssimo obrigado por estarem participando do tópico!

Perfeito o conceito de ambos. Se reparar as últimas postagem há um acordo geral entre todos.
Exatamente quando procurei entender a arquitetura do MVC o mais próximo do que podemos considerar correto foi exatamente o poder que ela proporcionará em futuras manutenções do código e escalabilidade.

Agora se deu controlador é 'esperto' o suficiente para modelar toda a parte de logica da aplicação de forma que a visão tenha acesso apenas a serviços e os beans/POJOs de sua aplicação, acredito que a visão ficará totalmente desacoplada do model, conhecendo apenas a camada do controlador.

Quando se diz serviços está se referindo aos métodos do controle, quando chamados, chamam os métodos no modelo necessários para alterá-lo? É isso?

Fiz um esqueminha de como estou enxergando a implementação do MVC até este momento para ver se estou no caminho certo. (imagem em anexo)

Ah, essas duas dúvidas que postei anteriormente ficaram em aberto:
Dúvida 1 é a seguinte: O Controlador é acionado através de eventos? Ou seja, o controlador é um Listener?
Dúvida 2 é a seguinte: O Controlador é quem decide a troca de visão?

Muito Obrigado pessoal por estarem participando do tópico e gostando. Fico muito feliz em saber que está sendo útil para toda a comunidade!

Por favor, não deixe de participar do tópico. Sua ajuda é muito importante para nós! Obrigado, fico no aguardo por mais respostas!

Veja como o projeto Griffon trabalha pra voce entender melhor como aplicar MVC em aplicativos Desktop

http://griffon.codehaus.org/

T+

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

Obrigado Proteu por participar!

Legal o link vou estuda-lo para conseguir ganhar novas informações! Parece que lá tem o MVC aplicado ao Groovy... isso é novo para mim, vou estudar!

Enquanto isso as 3 perguntas anteriores a este dois últimos posts estão em aberto (Antes desse post e do Proteu).
Por favor, se souber a resposta não deixe de contribuir com a comunidade, sua resposta é importantíssima!
Fico no aguardo pelas respostas e mais uma vez muito obrigado a todos que estão contibuindo, mesmo aqueles que somente estão desprendendo do seu tempo em ler! Obrigado.

pedromuyala wrote:
Agora a dúvida 1 é a seguinte: O Controlador é acionado através de eventos? Ou seja, o controlador é um Listener?
E a nova dúvida 2 é a seguinte: O Controlador é quem decide a troca de visão?

Rapaz, da forma que eu aprendi, que não sei se é a mais utilizada, é receber o evento na visão (a visão é o listener), identifico qual evento é e o que deve ser feito, e chamo o método apropriado no controlador.

O que você quer dizer com troca de visão?

eu acredito que sim, se vocÊ for pegar o model 2 (que aliais é mais indicado para web), você vai ter la um lugar dizendo de onde para onde entre as paginas jsp. Por exemplo, no caso do JSF, vai ter la no faces-config uma tag navigation-rule, onde você diz de qual pagina você vai para qual pagina, de acordo com determinada situação. Mesmo em desktop eu considero legal você deixar essa informação em um unico lugar, para depois por exemplo saber onde procurar qual janela iria chamar a janela x. Eu não sei se para desktop o padrão seria esse (igualmente ao model 2 no caso de web) mais é o que eu indicaria

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

Olá Márcio, obrigado por continuar acompanhando o tópico!

marcio0 wrote:Rapaz, da forma que eu aprendi, que não sei se é a mais utilizada, é receber o evento na visão (a visão é o listener), identifico qual evento é e o que deve ser feito, e chamo o método apropriado no controlador.

Rapaz o Listener da visão não é para escutar os eventos lançados pelo modelo?
E a visão chama métodos do controlador ou passa eventos para ele? (user gestures)

O que você quer dizer com troca de visão?

Por exemplo, ao clicar em um botão da visão, ela muda a interface de gráfica para texto.
Ou então ela chama um outro jogo de MVC: Na visão está sendo apresentado o modelo da classe Pessoa. Ao clicar em um determinado botão lá presente, ela passa a exibir a visão cujo o modelo é da classe Carro.

Obrigadão Marcião por estar ajudando, fico no aguardo pelas respostas!:

Obrigado a todos que estão ajudando e somente acompanhando o andamento do tópico, agradeço muito!

Algo que venho pensando ultimamente é sobre o que realmente é o Model, no padrão MVC.

A ideia é desacoplar as camadas, ou seja, deixar as responsabilidades comuns juntas.

No entanto, Model poderia se tratar tanto de dominio de aplicação (beans/POJOs), quanto da lógica da aplicação(PessoaService).

Se Pararmos para refletir, devemos separar lógica de aplicação das Visões e dos Controladores, mas separar o modelo da aplicação das Visões é um pouco que paranoico..rsrs. Pois as visões devem refletir o dominio o qual busca captar e exibir os dados.

Partindo deste ponto de vista, teriamos um MVC, onde, agora sim, os papeis fazem sentidos em minha cabeça, onde, a visão fica responsavel por exibir/captar dados do usuario, o controlador responsavel por captar os eventos e determinar quem executará esta operação no modelo, e o modelo seria apenas a logica de negocio da aplicação. Sim! E os beans?! Esses sim estariam disponiveis para todas as camadas do MVC, por teoricamente não pertencer a nenhuma delas.

A grande coisa, penso eu, é que desta forma temos sim um sistema desacoplado tanto para um sistema Web quando Desktop, e podemos modificar somente as Vvisões e o sistema continuará a funcionar, lógico fazendo alguma alteração nos controladores, pois as requisições e captura de eventos nos paradigmas de desenvolvimento são diferentes. Mas no geral, ficaria desacoplado e teriamos um sistema de facil manutenibilidade.

Uffa....Acho que é essa minha humilde opinião. Lógico, gostaria de descutir isso tambem pois foi algo que como falei antes, é algo que venho pensando ultimante e futuramente no momento de projeto tentaria aplicar em projetos reais para ver o desempenho na fase de manutenção!

Att..

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

Olá Maior, obrigado por responder, continuar acompanhando e me desculpe pela demora em responder!

maior_abandonado wrote:eu acredito que sim, se vocÊ for pegar o model 2 (que aliais é mais indicado para web), você vai ter la um lugar dizendo de onde para onde entre as paginas jsp. Por exemplo, no caso do JSF, vai ter la no faces-config uma tag navigation-rule, onde você diz de qual pagina você vai para qual pagina, de acordo com determinada situação. Mesmo em desktop eu considero legal você deixar essa informação em um unico lugar, para depois por exemplo saber onde procurar qual janela iria chamar a janela x. Eu não sei se para desktop o padrão seria esse (igualmente ao model 2 no caso de web) mais é o que eu indicaria

Eu andei lendo sobre o MVC2 (model 2) e realmente é o que eles fazem. O controle é quem assume o papel de mudar a JSP.

O que dá impressão no Desktop ao me parecer é que os eventos lançados do modelo para a visão é que levam a própria visão a decidir o que deverá ser mostrado, ou seja, reenderizar a página atual ou trocar de página e reenderizar uma nova. CONTUDO, se reparar no esquema do MVC da própria SUN (Ver imagem em anexo no primeiro post desta página, a 11) eles dizem que o poder de trocar a visão é do controlador "seleciona a view". Mas sabe o que eu ponho em dúvida sobre esse esquema é o seguinte:

Imagine que a pessoa que mexe na visão digita um determinado dado que quando chega na visão ele gera uma exceção. Como o modelo não fala (não conhece) o controle, imaginamos que o controle vai trocar a visão sem saber se ocorreu uma exception ou não. Olha que situação catastrófica: Vai aparecer para o usuário uma tela dizendo "OK, opção aceita!" mas na verdade a opção foi é uma Exception!

Mais uma do capeta! Isso até foi discutido com o Bruno Laturner em posts anteriores. O problema foi solucionado, porém o controle não assumia a troca da visão. Na ocasião, ninguém mais assumiu troca (ficou indefinido quem troca a visão).

Por isso eu acreditei na idéia de quando o Model gerar o evento para a visão de que tudo correu bem então ela mesma (Vamos entender assim: A camada da visão) trocava a sua visão. O que acha??

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

Olá 71C4700, muitíssimo obrigado por continuar aqui conosco!

71C4700 wrote:Algo que venho pensando ultimamente é sobre o que realmente é o Model, no padrão MVC.

A ideia é desacoplar as camadas, ou seja, deixar as responsabilidades comuns juntas.

No entanto, Model poderia se tratar tanto de dominio de aplicação (beans/POJOs), quanto da lógica da aplicação(PessoaService).

Se Pararmos para refletir, devemos separar lógica de aplicação das Visões e dos Controladores, mas separar o modelo da aplicação das Visões é um pouco que paranoico..rsrs. Pois as visões devem refletir o dominio o qual busca captar e exibir os dados.

Partindo deste ponto de vista, teriamos um MVC, onde, agora sim, os papeis fazem sentidos em minha cabeça, onde, a visão fica responsavel por exibir/captar dados do usuario, o controlador responsavel por captar os eventos e determinar quem executará esta operação no modelo, e o modelo seria apenas a logica de negocio da aplicação. Sim! E os beans?! Esses sim estariam disponiveis para todas as camadas do MVC, por teoricamente não pertencer a nenhuma delas.

A grande coisa, penso eu, é que desta forma temos sim um sistema desacoplado tanto para um sistema Web quando Desktop, e podemos modificar somente as Vvisões e o sistema continuará a funcionar, lógico fazendo alguma alteração nos controladores, pois as requisições e captura de eventos nos paradigmas de desenvolvimento são diferentes. Mas no geral, ficaria desacoplado e teriamos um sistema de facil manutenibilidade.

Uffa....Acho que é essa minha humilde opinião. Lógico, gostaria de descutir isso tambem pois foi algo que como falei antes, é algo que venho pensando ultimante e futuramente no momento de projeto tentaria aplicar em projetos reais para ver o desempenho na fase de manutenção!

Att..

Legal a postagem o conceito está certinho, é esse mesmo.

Quanto aos beans estarem soltos para todas as camadas tenho dúvidas no quesito manutenção. Imagine se for alterado um desses beans o estrago estaria feito!

Mas mesmo assim eu gostei da idéia parece estar bem fácil de entender... gostaria que falasse mais sobre ela: Como a visão irá lançar os eventos ao controle? O Observer vai, via source do evento, levar o bean até a visão ou ele será agregado a ela? Quem vai trocar a visão, por exemplo, após digitar alguns valores e esse ser validado pela lógica de negócio mudar a tela avisando o usuário que os dados foram digitados com sucesso?

Fico no aguardo pelas respostas, muito legal!

Não tenha pressa em responder o legal é pensarmos em uma coisa real de realizar usando o conceito já existente.
Volto agradecer a paciência de todos os companheiro gujeiros. Estou tentando realizar um trabalho na questão de vincular outros tópicos a este para evitar que a comunidade fique tendo que repetir a mesma coisa em vários tópicos. Espero estar junto com todos colaborando para que o melhor possível seja realizado aqui no fórum GUJ. Um abraço.

acredito que o ideal para desenvolver MVC em desktop, pelo menos foi a abordagem que achei melhor durante o desenvolvimento de aplicações, foi utilizar listener e interfaces para simular esse MVC.

até investiguei o MVP, porem os exemplos ensinavam de forma errada, mantendo referencia circular dos objetos no sistema, ou seja, existiam objetos que nunca morriam (leia-se coletados pelo GC), e aos poucos isso tornava a aplicação lenta.

Porém com alguns ajustes conseguimos tornar a aplicação flexivel, nos aproveitando de listeners e interfaces.

Por que separei listener de interface, um listener extende normalmente a EventListener, que é a base para o Swing.

O que acontece, foi que defimos uma classe básica que extende a JFrame e implementa diversas funcionalidades padrões do sistema, logico que usando um pouco de Convension over Configuration. Todas as telas extendem dessa classe.
E os Controllers também derivam de uma classe que contem metodos comuns que podem ser sobrescritos, e metodos auxiliares para ajustes no codigo. E o listener, a interface que contem os metodos publicos do controller para a view poder chamar. A view conhece unica e exclusivamente o listener. E o controller nem faz ideia de quem ele manipula, somente durante a chamada a tela é passada como source do EventObject, ou seja, ao final do metodo o Controller perde a referencia dessa classe liberando assim ela da memoria. Lógico que existem também o padrão observer, que utilizamos para fazer comunicação entre as telas. e funciona muito bem.

Lógico que esse é um exemplo bem simples, mas na minha visão o MVC pra um pode não ser MVC para outro. O ponto de vista é muito importante.

[]' s

pedromuyala wrote:Legal a postagem o conceito está certinho, é esse mesmo.
Quanto aos beans estarem soltos para todas as camadas tenho dúvidas no quesito manutenção. Imagine se for alterado um desses beans o estrago estaria feito!
Mas mesmo assim eu gostei da idéia parece estar bem fácil de entender... gostaria que falasse mais sobre ela: Como a visão irá lançar os eventos ao controle? O Observer vai, via source do evento, levar o bean até a visão ou ele será agregado a ela? Quem vai trocar a visão, por exemplo, após digitar alguns valores e esse ser validado pela lógica de negócio mudar a tela avisando o usuário que os dados foram digitados com sucesso?

Se você precisa que mais de uma visão saiba da alteração de um objeto, talvez você deva usar o padrão publish-subscribe, notificando as telas e mandando elas se atualizarem com o valor.
A visão não precisa "lançar" os eventos, ela pode identificar qual é a requisição e chamar um metodo apropriado no controle. Se for o caso, um objeto será retornado.

Na visão:

A troca de visão pode depender do seu contexto. Acho que haverá casos que tanto faz a visão chamar a próxima visão ou o controle fazer a troca. Até porque, existe programação errada, mas não existe "A" programação certa. Se funciona, está de acordo com os requisitos, e você não está quebrando padrões ou convenções, está certo.

This message was edited 1 time. Last update was at 23/10/2009 18:51:07

Olá Felagund e Marcio, obrigado por participarem/acompanharem o tópico!

Estou respondendo com menor agilidade seguindo recomendações via MP dos companheiros para não dar impressão de estar forçando a resposta!

Então gostei muito, muito mesmo de todas as colaborações de todos os companheiros gujeiros que estiveram conosco participando, somente lendo ou criticando.

A atenção que cada companheiro disponibilizou do seu tempo aqui é um carinho que vale muito mais que qualquer coisa que podemos imaginar.

Mas preciso dizer uma coisa que andou ocorrendo aqui no fórum em diversos tópicos sobre MVC: Parece que existe uma (com desculpa da palavra) eterna confusão entre MVC e Camadas (tanto Tier quanto Layer) para alguns companheiros. Preciso assumir a todos que eu mesmo acreditava no MVC sendo uma arquitetura ideal para construção de um sistema independentemente do que seria desenvolvido mesmo lendo artigos de pessoas conceituadas com vaga experiência profissional.

Mas a essa altura e lendo as respostas nos diversos links relacionados na primeira postagem desse tópico ficou bem claro que não é bem esse o objetivo do MVC. Na verdade aprendi que um sistema deve ser desenvolvido em Layer's (para não dizer camadas e novamente tornar ambíguo com camadas físicas) e o MVC pode estar presente em uma Layer (Ex: MVC na Apresentação) ou em várias Layer's individualmente (Ex: 1 MVC na Apresentação e 1 MVC no Cliente) ou seja MVC's independentes. Não existe UM MVC para duas, três, n Layer's. O que existe é uma Layer onde pode ser aplicado o MVC mas não um MVC formado por várias Layer's, agora estou certo?

Portanto se isso que acabei de escrever tiver procedência real gostaria que fosse discutido então como funciona o MVC dentro de uma Layer.
Espero que agora sim as coisas comecem a fazer sentido na minha mente e pare de causar esse enorme desconforto entre os companheiros.

Preciso frizar uma coisa que já disse em tópicos anteriores: Eu estou aqui é para aprender, eu gosto dessa comunidade, gosto das pessoas que aqui participam e não tenho interesse nenhum por trás de tantas perguntas. O único interesse que tenho é igual a esse aí que acabei de escrever: Ajudar as pessoas, assim como a mim mesmo, a acabar com esses tipos de dúvidas que levam nossos amigos a eternas síndromes de confusão. E outra coisa que preciso frizar é para aqueles que acham que eu só quero audiência ao meu tópico.

Eu prefiro que meu tópico tenha 1000 respostas e 1000 visitas do que ter 50 mil visitas e nenhuma resposta.

Só posso desejar felicidades a todos e muita saúde.
Espero pelas respostas, um abraço!

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

pedromuyala wrote:
Mas a essa altura e lendo as respostas nos diversos links relacionados na primeira postagem desse tópico ficou bem claro que não é bem esse o objetivo do MVC. Na verdade aprendi que um sistema deve ser desenvolvido em Layer's (para não dizer camadas e novamente tornar ambíguo com camadas físicas) e o MVC pode estar presente em uma Layer (Ex: MVC na Apresentação) ou em várias Layer's individualmente (Ex: 1 MVC na Apresentação e 1 MVC no Cliente) ou seja MVC's independentes. Não existe UM MVC para duas, três, n Layer's. O que existe é uma Layer onde pode ser aplicado o MVC mas não um MVC formado por várias Layer's, agora estou certo?

Oi Pedro

Vamos lá então, deixa eu tentar colocar a minha opinião

At first glance, the three tiers may seem similar to the MVC (Model View Controller) concept; however, topologically they are different. A fundamental rule in a three-tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middleware tier. Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model.

http://en.wikipedia.org/wiki/Multitier_architecture

Ou seja, a separação física das camadas (tiers) diz que elas se comunicam linearmente. No exemplo de uma aplicação web você poderia dizer que o browser do cliente é uma camada, o application server onde fica a lógica de negócio é outra camada e o banco de dados é outra camada..

Essas seriam as camadas físicas do seu sistema

Já com relação a separação em camadas lógicas você poderia considerar que teriamos a tal separação de responsabilidades. O seu view irá enviar os inputs de dados para o seu controller, que irá atualizar o seu banco de dados e o seu view irá consultar (ou será avisado) pelo controller quando alguma alteração ocorrer

A grosso modo separar em camadas físicas significa que eu posso ir lá e arrancar pedaço do código, ou por exemplo, se o seu banco de dados cair uma camada vai junto.
Já separar logicamente significa que cada camada tem uma responsabilidade bem definida, e no caso de ela não ser mais suficiente você pode simplesmente substituir este pedaço da sua aplicação por outro pedaço que tem a mesma responsabilidade.

Se tiver tempo dê uma lida também nos artigos abaixo

http://srinivasrb.wordpress.com/2009/06/02/layers-and-tiers/

http://pranshujain.wordpress.com/2006/09/15/layers-and-tiers/

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

Olá André, puxa obrigadão por continuar participando!

Entendi direitinho cara a explicação. E acredito que a sua intensão foi me dizer, a princípio, para que eu estude Camadas, não é?

Até porque do jeito que você descreveu as camadas lógicas é exatamente o que eu preciso! Uma visão que envia dados ao seu controlador e realiza a persistência em banco de dados. Após isso a visão é avisada para se atualizar (e o Observer eu aprendi também em um link que você indicou

) Se em um modelo de camadas lógicas essas responsabilidades ficam definidas, é o que eu realmente procuro. E também entendi as camadas físicas, muito legal!

Poxa você sempre que pode me "destrava" em problemas enrolados. Acho que tem competência o suficiente para ser um moderador do GUJ, espero que leiam isso!

Obrigado mais uma vez, fico no aguardo pela resposta!

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

pedromuyala wrote:
Mas a essa altura e lendo as respostas nos diversos links relacionados na primeira postagem desse tópico ficou bem claro que não é bem esse o objetivo do MVC. Na verdade aprendi que um sistema deve ser desenvolvido em Layer's (para não dizer camadas e novamente tornar ambíguo com camadas físicas) e o MVC pode estar presente em uma Layer (Ex: MVC na Apresentação) ou em várias Layer's individualmente (Ex: 1 MVC na Apresentação e 1 MVC no Cliente) ou seja MVC's independentes. Não existe UM MVC para duas, três, n Layer's. O que existe é uma Layer onde pode ser aplicado o MVC mas não um MVC formado por várias Layer's, agora estou certo?

Sim.

Portanto se isso que acabei de escrever tiver procedência real gostaria que fosse discutido então como funciona o MVC dentro de uma Layer.

Todo o sistema que trabalha com informação ( e aqui se incluem até sistemas fisicos e quimicos) precisa de input e output.
Isto é essencial e obvio. Cada andar (layer) precisa destas coisas. Mas cada andar está empilhado em outros andares.
Isso significa que existe um input vindo de cima, um output indo para baixo e de volta.

OO diz que objetos devem ter responsabilidade unicas e separadas então a primeira coisa a fazer é criar dois objetos
um para a comunicação "acima" e outro para a comunicaão abaixo

cima <---> [ A .... B] <---> baixo

"A" será responsável por tratar o input de cima. Traduzi-lo para algo enterpretável pelo andar , isso será tratado e passado a B que traduzirá para o andar de baixo. B traduzirá a resposta de volta e A de volta ao andar de cima. Hum... será trtado por quem ?
PRecisamos deum terceiro objeto C, que fará o tratamento.

cima <---> [ A <--> C <--> B] <---> baixo

Esta é o design padrão de um andar. Agora imaginemos que este andar responde directamente ao usuário ou os comandos do usuário : teclas, mouse, etc... "A" estará disposto a responder a coisas como "usuario clicou em X" Este é o input que A recebe.
Mas não existe hora marcada para isso. Então entra o conceito de Evento. Algo acontece. Quando acontece isso desencadeia as chamadas aos andares de baixo. "A" é "activado" por um evento. Mas o evento é algo assincrono. Outro evento pode imediatamente seguir-se a esse. Um deslocar de mouse geram N eventos em pouco tempo. Então A não pode esperar pela resposta de C porque já precisa ficar disponivel para enviar outro evento. Esta cadeia de eventos força um processo assincrono em que a resposta não chega imediatamente. Mas quando ela chegar , A tem que ser informado. E quem sabe quando ela chega? O cada da outra ponta, B. Então a mecanica de eventos força uma separação

É um triangulo. A invoca C que invoca B que invoca A mas nunca a informação volta para quem chamou.
É deste triangulo que nasce o MVC.
M = modelo, é o nome de B. V = View é o nome de A e C = controler é o nome de C.

A view recebe o input e fornece o output ao andar superior. Model fornece o input e recebe o output do andar inferior. C controla o fluxo. Ele pode não chamar B e simplesmente enviar um evento a A, em nome de B.

Isto é o padrão. A implementação são outros 500.
Dependendo do propósito a implementação pode ser complexa ou não.

Não ha receita de como seria a implementação. O ponto é que se for no padrão MVC ela respeita certas regras de separação de responsabilidade. Mas lembre-se que MVC presupoe o uso de eventos. Deveria ser o padrão MVCE. Mas o que é um evento na relalidade ? como se implementa um ?

Em java isso é transparente. É a chamada a um método. Só que assim, não ha diferença entre um método-evento e um método normal. Pois. E por isso que é tão util e interessante, e simples em java trabalhar com eventos. Em outras linguagens um construto diferente de "método" é necessário para representar o evento.

É preciso tb deixar claro que MVC podem ser 3 objetos ou 1000 objetos. O M , o V e o C podem utilizar quandos objetos de tipos diferentes forem necessários. Normalmente uma implementação MVC é componentizada e cada componente assume um dos papeis do MVC. Como disse, a implementação pode ser simples ou complexa.

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