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

[marcio0]

[quote=pedromuyala]Pessoal estou perguntando um coisa que não existe?
Ou a pergunta está mal formulada?

Olhem só:

• Classe Carro faz parte do modelo. Um objeto carro é então criado;
• Classe CarroControl faz parte do controle. Um objeto carrocontrol é criado;
• O objeto carro então é agregado ao objeto carrocontrol;
• Por força maior, o objeto carrocontrol recebe um evento para modificar o objeto carro;
• Então o objeto carro é alterado e lança o evento “carroevent” (classe CarroEvent) aos Listener’s (visões) informando a alteração.

Nesse momento as visões que recebem o evento “carroevent” devem se reenderizar, mas aí vem o X da questão: A visão se atualizará com os valores que estão no evento “carroevent” usando os métodos get() [Ex: carroevent.getCor(), carroevent.getRoda(),…] ou vai usar o objeto carro agregada a ela e chamar os métodos get() de carro [Ex: carro.getCor(), carro.getRoda(),…] para tal? E pergunto ainda se essa segunda opção realmente existe, ou seja, um obejto do modelo deve ser agregado a visão para atualização ou isso não existe?

[/quote]
Infelizmente não li o tópico todo, entrei apenas de passagem, mas vou tentar ajudar.
Acredito que as visões recebem do controle um objeto carro (elas tem que conhecer o objeto, ou então receberão um monte de argumentos relativos aos valores alterados) e com esse objeto elas atualizam seus valores.
Algo tipo:
visão.update( carro );
Se as visões que necessitam dessa atualização não conhecerem a classe, terá que ficar assim:
visão.update( cor, placa, roda, … );
Procure pelo padrão de projeto observer (ou publish-subscribe). É exatamente o que você quer saber.
Espero ter ajudado, mesmo entrando no tópico aos 45 do segundo tempo e lendo só a última mensagem :-o

[pedromuyala]

Olá Marcio0, obrigado por iniciar a sua participação no tópico!
Não se preocupe em estar respondendo depois de 17162813836183 respostas.
Toda ajuda é muito bem vinda. Imagine se fossem 2726302323962423 omissões de respostas? :roll: Não existiria essa força que é hoje o Gujão. :lol:

Acredito que as visões recebem do controle um objeto carro (elas tem que conhecer o objeto, ou então receberão um monte de argumentos relativos aos valores alterados) e com esse objeto elas atualizam seus valores.

Então eu entendo que isso seria o mais simples em termos de desenvolvimento inicial, ou seja, a “visão conhece o modelo” mas o “modelo não conhece a visão”. Sendo assim se o modelo notificar (Observer) a visão sobre mudança de estado ela simplesmente se atualiza através dos gets do objeto do modelo. [Ex: carro.getCor(), carro.getPlaca(),…]

Só que dessa forma a minha visão estaria completamente acoplada ao modelo sendo que se algo for alterado na classe do modelo a visão sofre um impacto direto.
Lembrando que visões eu posso ter n de vários tipos diferentes. Imagine modificá-las! :shock:

:idea: Para garantir um bom desacoplamento das partes é que então me surgiu a idéia de transmitir as mudanças do modelo para a visão através do próprio evento de notificação. E usado junto com interfaces acredito que torna-se muito bom. Na verdade, a classe do evento implenta o EventObject que recebe como source o próprio objeto criador do evento [this].
Nesse evento existiram os métodos gets() necessários para realizar a atualização da visão(Listener) que recebe-lo. [Ex: carroEvent.getCor(), carroEvent.getPlaca(),…]

Mas como o pessoal tem muuuuuuuito mais experiência no mercado de trabalho e estudo que eu, o que estou aí dizendo pode ter consequências futuras desastrosas!!! :? :x :?

É complicado entender assim só com palavras. Vou acabar deixando os companheiros nervosos! :x Vou realizar uma implementação e postá-la para ficar ainda melhor de entender.

[size=16]Mas se alguém já tem alguma opinião, crítica tipo “nossa esse cara tá viajando, é um louco sem noção”, idéia, sugestão sobre a última postagem peço por favor não deixe de expressar sua reação enviando uma resposta. Sua resposta é muito importante, não se acanhe.[/size]

Para quem acredita que eu quero é ter audiência se engana eu prefiro ter um tópico com 100 visitas e 100 respostas do que ter um tópico com 1 milhão de visitas e sem nenhuma resposta mesmo que seja criticando. [color=darkred]Obrigado companheiros gujeiros vou implementar a idéia e posta-la! Volto a agradecer a todos que desprendem do seu limitado tempo aqui no tópico colaborando. Valew![/color] :thumbup:

[marcio0]

[quote=pedromuyala]Olá Marcio0, obrigado por iniciar a sua participação no tópico!
Não se preocupe em estar respondendo depois de 17162813836183 respostas.
Toda ajuda é muito bem vinda. Imagine se fossem 2726302323962423 omissões de respostas? :roll: Não existiria essa força que é hoje o Gujão. :lol:

Acredito que as visões recebem do controle um objeto carro (elas tem que conhecer o objeto, ou então receberão um monte de argumentos relativos aos valores alterados) e com esse objeto elas atualizam seus valores.

Então eu entendo que isso seria o mais simples em termos de desenvolvimento inicial, ou seja, a “visão conhece o modelo” mas o “modelo não conhece a visão”. Sendo assim se o modelo notificar (Observer) a visão sobre mudança de estado ela simplesmente se atualiza através dos gets do objeto do modelo. [Ex: carro.getCor(), carro.getPlaca(),…]

Só que dessa forma a minha visão estaria completamente acoplada ao modelo sendo que se algo for alterado na classe do modelo a visão sofre um impacto direto.
Lembrando que visões eu posso ter n de vários tipos diferentes. Imagine modificá-las! :shock:

:idea: Para garantir um bom desacoplamento das partes é que então me surgiu a idéia de transmitir as mudanças do modelo para a visão através do próprio evento de notificação. E usado junto com interfaces acredito que torna-se muito bom. Na verdade, a classe do evento implenta o EventObject que recebe como source o próprio objeto criador do evento [this].
Nesse evento existiram os métodos gets() necessários para realizar a atualização da visão(Listener) que recebe-lo. [Ex: carroEvent.getCor(), carroEvent.getPlaca(),…]
[/quote]
Eu entendo o que você disse.
Mas acho que esse acoplamento realmente deve existir. Se a visão trabalha com aquele modelo (a tela exibe as informações do carro), uma alteração no modelo tem que acontecer na tela também (a classe carro agora tem o numero de portas, a tela terá que apresentar isso).
Acho que entendi o que você sugeriu, mas nesse seu exemplo, se o modelo mudar, como a visão vai refletir isso?

[Andre_Fonseca]

oi Pedro,

Concordo com o Márcio, bom a minha opinião é a seguinte: (pensando bem alto nível, sem código nem nada)

A visão deve ser acoplada ao modelo, mas o modelo não deve ser acoplado a visão… pois acho que a visão, ou seja, a camada que se mostra ao usuário do software, apenas reflete o modelo, e neste caso ela está sim acoplada ao modelo.

Ja em contra-partida o modelo não deve ser acoplado a visão, pois se algum dia você precisar mudar a sua camada de apresentação você vai ter essa independência …

Lembrando que o modelo nada mais é do que uma representação dos objetos do dominio do mundo real, ou seja, se o seu dominio muda todo o resto deixa de fazer sentido, por isso o acoplamento…

t+

[pedromuyala]

Olá Márcio, muitíssimo obrigado por continuar ajudando aqui no tópico!

[quote=marcio0]Eu entendo o que você disse.
Mas acho que esse acoplamento realmente deve existir. Se a visão trabalha com aquele modelo (a tela exibe as informações do carro), uma alteração no modelo tem que acontecer na tela também (a classe carro agora tem o numero de portas, a tela terá que apresentar isso).
[/quote]

É realmente nesse caso de acrescentar atributos ao modelo teremos que implementar na visão, pode ser a visão conhecendo o modelo ou recebendo um evento. Nesse caso de acrescentar poderia fazer uso de Reflection. Mas acredito que estaria construindo um “canhão” para pegar uma formiguinha. Acho que estou começando a entender: O acoplamento é ruim quando ele foge de um contexto, estou certo? O desacoplamento é importante para reusar as partes mas se for pensar bem de nada adianta eu ter uma visão que mostra dados de uma pessoa desacoplada do modelo pessoa, até porque a visão pessoa não poderá ser usada no modelo do carro, concorda? :roll:

Acho que entendi o que você sugeriu, mas nesse seu exemplo, se o modelo mudar, como a visão vai refletir isso?

Então estava achando legal no evento pelo seguinte: Se eu alterar ou excluir algum método do modelo eu precisaria mudar somente na classe do evento sem precisar mexer nas n visões.
Porém não teria sentido nenhum um atributo da visão estar lá presente se ele não receberá nunca mais nenhum valor. Pior ainda a visão dizer “Vem com CD-Player? -> Sim” mas por alterações realizadas no modelo na verdade ele está dizendo sim não para um CD-Player mas sim para um Blu-Ray! :twisted: Do capeta essa última hein!

Entendi perfeitamente porque as partes devem estar acopladas no MVC e isso não é erro nenhum. :lol:
Legal Marcio eu tenho mais uma pergunta mas para não atropelar a resposta do André vou responde-la primeiro e volto a postar. É em relação ao controle já postarei. Um abração, muitíssimo obrigado, acredito eu que deixou bem claro essa interação entre Visão<->Modelo. Valew!

[pedromuyala]

Opa André, puxa muito obrigado por continuar atento ao tópico!

[quote=André Fonseca]oi Pedro,

Concordo com o Márcio, bom a minha opinião é a seguinte: (pensando bem alto nível, sem código nem nada)

A visão deve ser acoplada ao modelo, mas o modelo não deve ser acoplado a visão… pois acho que a visão, ou seja, a camada que se mostra ao usuário do software, apenas reflete o modelo, e neste caso ela está sim acoplada ao modelo.

Ja em contra-partida o modelo não deve ser acoplado a visão, pois se algum dia você precisar mudar a sua camada de apresentação você vai ter essa independência …

Lembrando que o modelo nada mais é do que uma representação dos objetos do dominio do mundo real, ou seja, se o seu dominio muda todo o resto deixa de fazer sentido, por isso o acoplamento…

t+[/quote]

André, deixa eu entender uma coisa: Você falou em “objetos do domínio do mundo real”. O MVC é uma arquitetura para construção de um sistema (no meu caso Desktop mas se aplica outros) ou ele faz parte da arquitetura Layers (camadas)? Porque eu até este momento entendo que o domínio (Bean’s, DAO’s,…) é o M do MVC. [Ex: Pessoa.class, Carro.class, Guitarra.class]. Estou errado né? O certo é eu pensar em camadas não é?

Muito obrigado André, fico no aguardo pela resposta! E fico no aguardo de todos que quiserem participar!
[color=red]Obrigado[/color]

[maior_abandonado]

[quote=pedromuyala]Opa André, puxa muito obrigado por continuar atento ao tópico!

[quote=André Fonseca]oi Pedro,

Concordo com o Márcio, bom a minha opinião é a seguinte: (pensando bem alto nível, sem código nem nada)

A visão deve ser acoplada ao modelo, mas o modelo não deve ser acoplado a visão… pois acho que a visão, ou seja, a camada que se mostra ao usuário do software, apenas reflete o modelo, e neste caso ela está sim acoplada ao modelo.

Ja em contra-partida o modelo não deve ser acoplado a visão, pois se algum dia você precisar mudar a sua camada de apresentação você vai ter essa independência …

Lembrando que o modelo nada mais é do que uma representação dos objetos do dominio do mundo real, ou seja, se o seu dominio muda todo o resto deixa de fazer sentido, por isso o acoplamento…

t+[/quote]

André, deixa eu entender uma coisa: Você falou em “objetos do domínio do mundo real”. O MVC é uma arquitetura para construção de um sistema (no meu caso Desktop mas se aplica outros) ou ele faz parte da arquitetura Layers (camadas)? Porque eu até este momento entendo que o domínio (Bean’s, DAO’s,…) é o M do MVC. [Ex: Pessoa.class, Carro.class, Guitarra.class]. Estou errado né? O certo é eu pensar em camadas não é?

Muito obrigado André, fico no aguardo pela resposta! E fico no aguardo de todos que quiserem participar!
[color=red]Obrigado[/color]
[/quote]

bom… eu ja li algumas coisas de gente que intende mais do que eu, vi umas contribuições legais aqui mesmo no guj… acho que da pra eu dar meu pitaco…rs

vamos diferenciar um pouco, eixste o 3-tier e o MVC. 3-tier seria programação em 3 camadas, MVC possue 3 camadas, mais assim mesmo não são iguais. Respondendo a sua pergunta, sim, em MVC você deve pensar um pouco em camadas mas isso apenas para separar o comportamento, a visão é o cara que vai exibir o output para o user, o controle é o cara que vai decidir para onde a aplicação vai, qual vai ser o modelo chamado, qual view vai ser apresentada depois disso… modelo basicamente é o resto (persistencia, regras de negocio, log, envio de emails…) mas apesar de estar separado em camadas, o foco ao menos na minha opinião seria você pensar em comportamentos, em responsabilidades, e separar cada uma destas 3 principais em uma camada. Acreditoque isso responderia a sua ultima pergunta se deve pensar em camadas, elas são uma forma de você manter a sua aplicação de um jeito que permita mais facil manutenção, que facilite vocÊ a portar a aplicação de desktop para web ou vice versa, esse tipo de coisa, mais procure ter um foco no comportamento…

o 3 tier que me parece levar mais em consideração o uso de “camadas”, serie apresentação - regras de negocio - persistencia, no MVC o modelo fica com as 2 ultimas do 3 tier, mais denovo, no MVC se preocupe mais com o “como” do que com o “onde”, claro que sempre respeitando boas praticas também no que esta relacionado ao onde…

Porque eu até este momento entendo que o domínio (Bean’s, DAO’s,…) é o M do MVC. [Ex: Pessoa.class, Carro.class, Guitarra.class]

estes exemplos de classes que você deu são entidades, ou VOs, ficam no modelo. Beans e DAOs também…

bom…espero ter ajudado… depois eu tendo um pokinho mais de tempo eu volto e comento um poco mais isso.

[pedromuyala]

Olá Maior_Abandonado, muito obrigado por participar do tópico!

Entendi sim, agora ficou bem legal. Devo focar o comportamento. As camadas me ajudam a separar cada uma das letras do MVC, mas o comportamento entre elas é o foco.

o controle é o cara que vai decidir para onde a aplicação vai, qual vai ser o modelo chamado, qual view vai ser apresentada depois disso…

Então essa teoria do controlador que ainda tenho dúvidas. Mas vou explicar bem detalhado para ver se existe um acordo:

• Já aprendi aqui no tópico que o controlador conhece o seu modelo, ou seja, um modelo é agregado a ele. Isso para que o controlador possa alterar o modelo. Esse acoplamento é normal e real;
• Outra coisa importante é que o controlador (Isso no Desktop) não recebe nada do modelo como resposta. Ele somente aciona os métodos necessários no modelo para que possa ser alterado;

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?

[size=15]Companheiros quero agradecer muito pela força que estão realizando aí no tópico. Está sendo muito útil para todos que querem aprender mesmo de vez como funciona o MVC aplicado em sistemas Desktop.

Fico no aguardo pelas respostas, não se acanhe para responder todos nós estamos aqui para aprender.
[color=orange]Muito, muito Obrigado![/color]
[/size]

[Andre_Fonseca]

André, deixa eu entender uma coisa: Você falou em “objetos do domínio do mundo real”. O MVC é uma arquitetura para construção de um sistema (no meu caso Desktop mas se aplica outros) ou ele faz parte da arquitetura Layers (camadas)? Porque eu até este momento entendo que o domínio (Bean’s, DAO’s,…) é o M do MVC. [Ex: Pessoa.class, Carro.class, Guitarra.class]. Estou errado né? O certo é eu pensar em camadas não é?

Muito obrigado André, fico no aguardo pela resposta! E fico no aguardo de todos que quiserem participar!
[color=red]Obrigado[/color]

O MVC na minha opinião nada mais é do que uma separação de responsabilidades. No mundo orientado a objetos é considerado uma boa prática que cada objeto seu tenha suas responsabilidades bem definidas e se preocupe apenas em resolver estas responsabilidades. Existe até um termo usado para isso, se quiser depois pode dar uma olhada aqui

Isso de separar em camadas é muito subjetivo, como foi dito existem arquiteturas de 3 camadas, 4 camadas, n camadas… etc Lembrando ainda que mesmo o MVC que hoje é considerado 3 camadas antes era considerado 2 camadas, quando você tinha uma scriptlet gigante com toda a lógica de negócio dentro dela…

Não se preocupe em deixar o seu sistema com 2, 3, 4, n camadas, se preocupe em deixar os seus objetos simples o suficiente para fazerem bem o papel deles, se o seu DAO consegue abstrair o acesso ao banco e faz isso bem feito não importa em que camada você diga que ele pertença…

[71C4700]

Concordo com o André Fonseca, mais importante que conseguir modularizar todos o seu sistema é, fazê-lo de uma forma que quando for realizar a manutenção seja simples a implementação de uma alteração ou mesmo uma mudança em alguma ‘camada’.

Quando ao problema o grande lance a ser notado, em minha humilde optica, é que a visão deve refletir o modelo, logo, falando conceitualmente, esta de certa forma deveria conhecer o modelo/dominio o qual esta correlacionada.

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.

Sempre vejo que os beans/POJOs da aplicação não deveriam ser classificados/identificados como model, bem…muitos vão dizer mais o modelo não é o dominio do sistema, sim mas, alem de tudo, o modelo deve conter a logica de negocio, e esta refletir para a visão, ou atraves do controlador ou pelo uso direto do padrão Observer.

Com uma separação razoavel de responsabilidades, seria possivel transpor um sistema WEB para um desktop alterando apenas a View, está é acredito eu, a grade dficuldade de se trabalhar com a modularização.

Espero não ter apenas enxido linguiça(sem trema…rsrs), e possa ter contribuido com o caminhar da discurção que está muito boa e proveitosa, diga-se por passagem.

Att…

[pedromuyala]

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. [color=red](imagem em anexo)[/color]

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?

[color=blue][size=16]Muito Obrigado pessoal por estarem participando do tópico e gostando. Fico muito feliz em saber que está sendo útil para toda a comunidade! :D[/size][/color]
[size=14]Por favor, não deixe de participar do tópico. Sua ajuda é muito importante para nós! Obrigado, fico no aguardo por mais respostas![/size] :thumbup:

[Proteu_Alcebidiano]

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

http://griffon.codehaus.org/

T+

[pedromuyala]

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!

[size=15]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![/size]
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.

[marcio0]

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?

[maior_abandonado]

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

[pedromuyala]

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

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.

[color=red]Obrigadão Marcião por estar ajudando, fico no aguardo pelas respostas!:[/color] :thumbup:
Obrigado a todos que estão ajudando e somente acompanhando o andamento do tópico, agradeço muito!

[71C4700]

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…

[pedromuyala]

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

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! :twisted: 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). :shock:

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?? :roll:

[pedromuyala]

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

[quote=71C4700]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…[/quote]

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?

[size=16]Fico no aguardo pelas respostas, muito legal![/size]
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.

[Felagund]

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