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

[Lavieri]

[quote=pedromuyala]

1. É normal o modelo ter uma coleção de Listener’s que possa registrar as visões que implementarão esse mesmo Listener e passarão a receber eventos de “notificação de alteração” do modelo?[/quote]

Eu entendo que não, eu não faria assim, no meu entender o normal, é o controle implementar esses entityListener, de forma a repassar corretamente para a visão… A Visão não deve estar acoplada ao modelo.

[quote=pedromuyala]2) É normal a visão ter uma coleção de Listener’s que possa registrar os controladores que implementarão esse mesmo Listener e passarão a receber os eventos de “user gestures (Ex: Click’s,etc…)” da visão?[/quote] Eu entende que sim, o controle escuta a visão, de forma a encaminhas os eventos para o local correto do modelo.

[quote=pedromuyala]3) Vários controladores podem escutar a visão assim como várias visões podem escutar o modelo (desde que se registrem como ouvintes)?
[/quote] Varios controles podem escutar a visão sim…

O Ideal é que a visão não escute o modelo (na minha opinião claro) e sim o controle, que faria então a intermediação,

o que entendo que a visão conhece diretamente do modelo são no maximo as entidades, ou seja ele pode conhecer uma informação, e exibir ela na tela.

essa é a opinião que tenho

[sergiotaborda]

Não há dúvidas que o conceito está bem claro para mim. Que coisa, acho que agora estou conseguindo entender definitivamente seu raciocínio…
Mesmo assim, ainda preciso fazer três perguntinhas:

1. É normal o modelo ter uma coleção de Listener’s que possa registrar as visões que implementarão esse mesmo Listener e passarão a receber eventos de “notificação de alteração” do modelo?

Sim é normal.
Conceptualmente a visão que se registra no model para este a avise quando mudar. Se não fosse assim, como a visão saberia que o modelo mudou?

2. É normal a visão ter uma coleção de Listener’s que possa registrar os controladores que implementarão esse mesmo Listener e passarão a receber os eventos de “user gestures (Ex: Click’s,etc…)” da visão?

Não. Cada visão tem apenas um controlador. Ela repasse os eventos sempre ao mesmo controlador.
O que pode acontecer é mudar a visão associada ao controlador. Mas num dado momento só existe uma associada ( No swing a visão é o look&feel, só existe um por componente num dado momento. o componente é o controlador)

3. Vários controladores podem escutar a visão assim como várias visões podem escutar o modelo (desde que se registrem como ouvintes)?

Não. Várias visões ouvem o mesmo modelo Mas cada visão só tem um controlador e cada controlador só tem uma visão e um modelo.
O que pode acotecer é que o controlador A está ligado ao mesmo modelo que o controlador B.

[ingridfarabulini]

[quote=Lavieri][quote=pedromuyala]

1. É normal o modelo ter uma coleção de Listener’s que possa registrar as visões que implementarão esse mesmo Listener e passarão a receber eventos de “notificação de alteração” do modelo?[/quote]

Eu entendo que não, eu não faria assim, no meu entender o normal, é o controle implementar esses entityListener, de forma a repassar corretamente para a visão… A Visão não deve estar acoplada ao modelo.

[quote=pedromuyala]2) É normal a visão ter uma coleção de Listener’s que possa registrar os controladores que implementarão esse mesmo Listener e passarão a receber os eventos de “user gestures (Ex: Click’s,etc…)” da visão?[/quote] Eu entende que sim, o controle escuta a visão, de forma a encaminhas os eventos para o local correto do modelo.

[quote=pedromuyala]3) Vários controladores podem escutar a visão assim como várias visões podem escutar o modelo (desde que se registrem como ouvintes)?
[/quote] Varios controles podem escutar a visão sim…

O Ideal é que a visão não escute o modelo (na minha opinião claro) e sim o controle, que faria então a intermediação,

o que entendo que a visão conhece diretamente do modelo são no maximo as entidades, ou seja ele pode conhecer uma informação, e exibir ela na tela.

essa é a opinião que tenho

[/quote]

Olá lavieri ,

Isso que está parecendo ser MVP, não? Esse controle não seria um presenter?

Não. Cada visão tem apenas um controlador. Ela repasse os eventos sempre ao mesmo controlador.
O que pode acontecer é mudar a visão associada ao controlador. Mas num dado momento só existe uma associada ( No swing a visão é o look&feel, só existe um por componente num dado momento. o componente é o controlador)

Olá Sergio,

Então o controle e a visão se comunicam diretamente [1 para 1] assim como o controle se comunica diretamente com o modelo [1 para 1].
Porque a visão lança “eventos” para o controle ao invés de chamar um método diretamente do controle, como control.somaUm(); ?
Não é necessário usar o padrão Observer entre visão e controle?

Obrigada!

[sergiotaborda]

Então o controle e a visão se comunicam diretamente [1 para 1] assim como o controle se comunica diretamente com o modelo [1 para 1].
Porque a visão lança “eventos” para o controle ao invés de chamar um método diretamente do controle, como control.somaUm(); ?
Não é necessário usar o padrão Observer entre visão e controle?

Para responder a isso temos que entender primeiro o conceito de mensagem OO.
Na realidade pura os componentes mvc comunicam via o envio de mensagens.
A questão é que existem duas formas de enviar mensagens de um objeto para o outro.

1. chamar métodos no outro objeto (mecanismo sincrono)
2. o padrão Observer (mecanismo assincrono)

A comunicação entre a visão e o controlador é por eventos porque a interação do cliente com a view é assincrona não porque ha mais do que um ouvinte.

Se vc imaginar que a view do JTable apenas aciona comandos relacionados ao JTable ( cellClick, por exemplo) faz sentido.
Só que, em UI um outro padrão bom de usar é Composite Object.

Quando vc compoe os objetos numa estrutura semelhante a uma arvore, vc tem a capacidade de interceptar os eventos antes que cheguem no componente. É por exemplo o papel do GlassPane. Porque existe este mecanismo de intercepção precisamos de um mecanismo de eventos.

Portanto, da view para o componente vamos de lançamento de eventos assincrono para tirar partido do assincronismo (o componente só responde quando algo acontece com ele) e da composição.

A cardinalidade (1-1) não está diretamente relacionada ao padrão Observer. Vc pode usar observer mesmo quando é 1-1, a diferença é que quando é 1-n , vc só pode usar observer.

Da mesma forma que não faz sentido uma view mandar comandos a mais que um controlador, tb não faz sentido um controlador ter mais que um modelo. Mas aqui, nada nos impede de ter controladores diferentes baseados no mesmo modelo. Por exemplo, é comum que a mesma action de um botão da toolbar seja tb a action do item de menu que faz a mesma coisa. A representação mudou, mas o modelo não.

Do modelo para a view, a ligação é com eventos por causa, mais uma vez , do assincronismo não da cardinalidade. Quando o modelo muda, por causa da logica do sistema ( por exemplo, outro utilizador adicionou mais um item na lista) o modelo indica à view que mudou. Isto é equivalente ao usuário dar um comando quando ele sabe que os dados mudaram, o problema é que ele não tem como saber isso. então o próprio modelo avisa a view para dar um “refresh”.

O conceito é : o uso do padrão observer deve-se à necessidade de assincronismo , e nada tem que ver com a cardinalidade.

View <- 1 — 1-> Controlador <-----1-> Model <-1—-> View

outra forma de ver é que as consultas são feita sincronamente, portanto quando o view pega os dados do model só pode ser 1 model porque a chamada é sincrona. Quando o controlador comanda o modelo, é síncrono, portanto tem que ser 1 modelo.

[pedromuyala]

Fala companheiros, boa noite!

Poxa muito legal essa última explicação postada pelo Sergio em resposta a Ingrid, bem legal mesmo. Além que eu já havia perguntado isso em uma postagem anterior e ele mesmo havia respondido mas agora sanou de vez qualquer dúvida, parabéns! Também quero agradecer por ter respondido as minhas perguntinhas antes de tudo isso! :lol:

Poxa, posso estar enganado, ou melhor, acredito estar sim… mas a pergunta da Ingrid me pareceu bem inteligente para acrescentar mais um conceito a explicação: Acoplamento/Desacoplamento de sistema. Segundo estudos no passado, o Observer é uma forma de desacoplar as partes, certo?

Então pergunto, aproveitando o embalo: O Sergio já explicou que a cardinalidade nada quer dizer com relação ao uso do design pattern Observer.
Se for pensar em desacoplar as partes, então o que é mais desacoplado no MVC: Chamar diretamente o método de outra classe (visão chama métodos diretamente do controle) ou usar o Observer, mesmo que seja síncrono?

O que estou imaginando é o seguinte, lembrando que os conceitos são uma abstração: (imaginando que estou desenvolvendo um sistema que ao apertar o botão aumenta 1 no valor)

• A camada de Cliente fica definida como sendo composta por três classes: V.class, C.class e M.class
• V é a Visão; C é o Controlador e M o Modelo.
• V é um JFrame com um JPanel que possui um JButton.
• C possui métodos que alteram M.
• M possui um atributo int e um método que soma 1 a esse atributo quando chamado.

Tendo isso em mente…
Implemento Observer para V enviar eventos à C (que nesse caso só pode ser o clique no botão) e outro Observer para a M notificar V? ou
Faço V chamar métodos de C diretamente e implemento Observer para M notificar V? ou
Continuo com graves problemas em entender corretamente o conceito de Camadas e MVC portanto recomendaria, como disse anteriormente, mudar de ramo e abrir um Pet Shop? :oops:

Fico no aguardo guerreiros companheiros!
Muito obrigado por dispor seu tempo ajudando ou simplesmente lendo as postagens. Para mim, é uma honra.

[ingridfarabulini]

Olá Sergio

Entendi o conceito… ficou bem explicadinho.

Poxa, posso estar enganado, ou melhor, acredito estar sim… mas a pergunta da Ingrid me pareceu bem inteligente para acrescentar mais um conceito a explicação: Acoplamento/Desacoplamento de sistema. Segundo estudos no passado, o Observer é uma forma de desacoplar as partes, certo?

Você esta perguntando em aplicar o Observer para desacoplar o trio MVC ? Essa eu também quero saber kkkk… :?:

Então pergunto, aproveitando o embalo: O Sergio já explicou que a cardinalidade nada quer dizer com relação ao uso do design pattern Observer.
Se for pensar em desacoplar as partes, então o que é mais desacoplado no MVC: Chamar diretamente o método de outra classe (visão chama métodos diretamente do controle) ou usar o Observer, mesmo que seja síncrono?

O que estou imaginando é o seguinte, lembrando que os conceitos são uma abstração: (imaginando que estou desenvolvendo um sistema que ao apertar o botão aumenta 1 no valor)

• A camada de Cliente fica definida como sendo composta por três classes: V.class, C.class e M.class
• V é a Visão; C é o Controlador e M o Modelo.
• V é um JFrame com um JPanel que possui um JButton.
• C possui métodos que alteram M.
• M possui um atributo int e um método que soma 1 a esse atributo quando chamado.

Tendo isso em mente…
Implemento Observer para V enviar eventos à C (que nesse caso só pode ser o clique no botão) e outro Observer para a M notificar V? ou
Faço V chamar métodos de C diretamente e implemento Observer para M notificar V? ou
Continuo com graves problemas em entender corretamente o conceito de Camadas e MVC portanto recomendaria, como disse anteriormente, mudar de ramo e abrir um Pet Shop? :oops:

Eu acho que está certo sim a sua divisão, acho :!: E também acho que o certo é
Faço V chamar métodos de C diretamente e implemento Observer para M notificar V? ou

Mas é melhor você aguardar as repostas dos outros porque eu ACHO…

Obrigada

[pedromuyala]

Olá Ingrid!
Não precisa agradecer, eu quem agradeço pela ajuda!

Opa acredito na sua opinião… é muito importante!
Também acredito que é essa a ideia… mas como você mesmo sugere, vou continuar no aguardo a pergunta que fiz aí dois post’s acima e ver se o pessoal tem outra visão diferente da nossa.

Sei lá… sinceramente acho que a forma que dividi o MVC está cheirando a erro…

[Lavieri]

Voltando ao que falei la em cima, e que acho que não fui bem interpretado… não acho errado a visão ouvir o modelo … acho errado a visão se registrar no modelo, para ouvilo, esse trabalho deve ser mais do controle, isso é o que acredito…

…

Sobre o que foi falando acim com os observers,

M e principalmente M, não deve nem saber que existe V …

O Modelo existe com a lógica de negocio, e ele deve ser independente da visão o maximo que você conseguir.

…

Ai vamos o motivo da existencia do controle… A Colocar decisões dentro do modelo (mesmo que estas sejam de fluxo) não é bom, e é ai que entra o controle…

o contrlle existe principalmente para mediar o meio de campo… A View deve conhecer do modelo apenas as informações, ou seja, deve conhecer Beans ou Entidade que contenham informações a serem exibidas ou coisas do genero.

C, o Controller existe para agrupar a “pseudo lógica” da visão, ou seja, ele existe para Converter as informações da visão em informações legiveis para o Modelo, e quando necessário fazer o mesmo transformando as informações do Modelo em informações legiveis para a Visão.

Além disso é de responsabilidade do Controller conhecer o fluxo do sistema, ou seja, ele deve saber encaminhar uma ação vinda da View, e direcionar para o local correto no Modelo, se houver retorno do Modelo, é geralmente trabalho de C o Controller devolvero retorno a VIEW…

Mesmo no caso de uso de Observer, as coisas continuam passando pelo controller, pq é ele quem registra uma Visão em um Modelo (quando possivel!, quando isto é compativel, quando não é compativel o controle é responsável por intermediar fazendo o papel do adaptador), portanto neste caso, mesmo que o FIRE do observerdo modelo vá direto a VIEW quem a colocou lá foi o controller, e foi através dele que essa informação foi parar no local correto, afinal essa é a função do controle.

…

Pq esse papel do C ? no meio de campo ? pq não fazer essas coisas na view ? o motivo é para deichar o código mais coeso.

dentro do Modelo há toda sua lógica o ideal é que vc seja capaz de um dia, se quiser, mudar a VIEW sem abalar o seu modelo, e assim seu código pode ser bastante reutilizável.

dentro da sua View não deve existir código do modelo, exceto os de uso de informação, ou seja, partes do modelo que são informação, e não os que são processamente… partes do modelo que servem para trazer infomação ou levar informação

dentro do seu controle, bom, como no modelo não pode ter NADA da view, como no sua view só pode ter objetos que carregam ou levam informações do modelo,

• alguem tem que fazer as ligações, alguem tem q levar a informação que o usuário passa através de uma view, la pra baixo para o modelo.
• alguem tem que pegar o processamento do modelo, e devolver a informação para a view correta, de forma que o usuário tenha interação com o sistema.
• alguem tem que ser responsavel por ligar a VIEW ao MODELO e esse alguem é o CONTROLE.

…

Bom esse é o meu intendimento do assunto, e é assim que faria/faço … não vejo motivos para uma view acessar diretamente o modelo, mesmo que para se registrar com observer, não é trabalho da view saber onde se registrar e sim do controller…

Ficam ai minhas observações…

Ps.: Cuidado com o entendimento de MVC em varias camadas, isso é possivel sim, mas não é prache e nem sempre a melhor forma de se fazer… um MVC existe onde você conseguir enchergar um MODELO e uma VIEW … a interface da sua camada pode sim ser conciderada uma VIEW (quando falo interface, falo do limiar da camada que é usado pela camada superior), mas ai vc esta levando em concideração que pode trocala por algum motivo, se não houver como trocar esqueca, e escreva um MVC só pra uma camada…

Lembrando que, GUI, páginas web, são lógicamente views, e portanto é sempre bom pensar em MVC quando usalas.

[71C4700]

Se pensarmos da seguinte forma: O controlador deve apenas receber as notificações da visão e repasá-la ao modelo. O Modelo deveria, então, trata da forma a qual fosse mais conviniente.

Sendo assim, teriamos algo mais simples, onde o controlador apenas seria ouvinte dos eventos que ocorrem na visão, e tambem poderia ser o objeto observado pelo modelo. Ai teriamos uma divisão bem legal, pois o controlador nao precisaria conhecer o modelo, nem a visão o controlador. Ocorreia apenas um ‘conhecimento unidirecional’ entre as camadas subadjacentes. E teriamos uma forma simples de realizar a manutenção no codigo, pois teriamos apenas a alteração em uma camada, não refletindo na outra, nem mesmo quando a lógica, ou a forma que o controlador é notificado pela visão nem tao pouco quando a visão mudasse.

Lógico, são opiniões que podem estar um pouco vagas, mas acredito que dessa forma poderiamos ter uma maior escalabilidade e manutenibilidade no software.

Att…

[Lavieri]

[quote=71C4700]Se pensarmos da seguinte forma: O controlador deve apenas receber as notificações da visão e repasá-la ao modelo. O Modelo deveria, então, trata da forma a qual fosse mais conviniente.

Sendo assim, teriamos algo mais simples, onde o controlador apenas seria ouvinte dos eventos que ocorrem na visão, e tambem poderia ser o objeto observado pelo modelo…[/quote]

É aqui onde mora o problema… se o Modelo conhecer o controle, vc fica incapacitado de pegar o mesmo modelo e usar com uma visão diferente…

O papel do controle é de intermedirar o assunto, então inevitavelmente ele vai ter que conhecer os 2…

[71C4700]

Neste caso o modelo apenas seria ouvinte do controlador. Não tendo, entao, a necessidade de conhece-los, podendo ser aplicado tanto pra Web quanto pra Desktop.

Assim penso, pois o modelo pode mudar, e essa mudança deve revletir o minimo possivel. Nesta solução, teriamos que alterar apenas a visão sobre alguma modificaçao no modelo, nao tendo necessidade de alterar o controlador. Mas esta mudança na visão seria apenas se alguma informaçao na notificação ou alteração na estrutura dos objetos trocados entre visão e modelo, pelas notificações.

Att…

[Lavieri]

Neste caso o modelo apenas seria ouvinte do controlador. Não tendo, entao, a necessidade de conhece-los, podendo ser aplicado tanto pra Web quanto pra Desktop. …

Como vai ser ouvinte de alguem sem conhecelo ? … o que vc chama de ser ouvinte sem cohecelo ? (Obs.: entenda que não estou criticando que isso não possa acontecer, tanto que é o que afirmei acima, e o que tento explicar novamente abaixo)

o Modelo pode ter espaço para registro de observer(isso não o torna informante do controle e sim um local de onde informações são enviadas, seja pra onde for) , ou espaço de registro para entrada de eventos (isso não os torna ouvinte de evento do controle, e sim receptivo a eventos externos, o que faz o estado do modelo alterar, ou uma cadeia de eventos ocorrer), isto não implica que ele conheça o controller, ou que ele esteja ligado de alguma forma ao controller…

o Modelo continua sozinho, com espaços para receber informação/eventos, e espaços para enviar informações/eventos… ficando desacoplado totalmente da visão ou controle.

assim… o Controle precisa conhecer o modelo, pois o modelo não vai chamar a visão para ser registrada nela, nem mesmo o modelo, ele apenas tem lugares onde isso pode ser feito, mas quem tem que fazer é o controle, e para tal ele vai precisar conhcer o modelo, e como o que o controle vai ligar ao modelo é a visão, ele acaba conhecendo os 2, e não da pra fugir muito disso =/

[pedromuyala]

Olá pessoal, muito obrigado pela participação de todos! Fico muito contente em ver o interesse do pessoal!

Nós estamos aqui neste tópico há alguns meses debatendo com muitos profissionais (especialistas ou não) em suas diferentes áreas de atuação. O que nota-se claramente é um certo “desacordo” entre os diversos lados sobre um tema que tem como definição “pattern” (padrão), ou seja, um assunto que deveria ser igualmente entendido por todos, no nosso caso, o MVC.

A minha real intensão para criação deste tópico era debater algo que as pessoas conseguissem realmente entender e resolver suas dúvidas sobre o pattern MVC. Só não acreditava que esses problemas fossem tão ramificados e difíceis de serem resolvidos de forma que houvesse um acordo geral entre a maioria de nós.

Mas tem alguns detalhes do MVC que parecem estar de acordo com a grande maioria das pessoas, os quais só consegui perceber depois desses meses de debate. São eles:

1 ) MVC funciona bem quando aplicado de forma integrada/indivisível/impartível a Camada. Geralmente não se parte o trio MVC para abrangir várias camadas. Cada uma tem o seu MVC próprio, quando necessário. Ex’s:
Ex1 - a) MVC aplicado a Camada de Apresentação;
Ex1 - b) MVC aplicado a Camada de Cliente;
Ex1 - c) Um MVC aplicado a Camada de Apresentação e outro MVC aplicado a Camada de Cliente seu um mesmo sistema.

2 ) No MVC entende-se como entrada/exibição de dados o V de Visão. Ex’s:
Ex2 - a) (Como Entrada) O usuário interage clicando/teclando em um JButton (ou qualquer outro componente que gera um evento para a Visão);
Ex2 - b) (Como Exibição) Exibe a interface gráfica de determinado componente ao usúario;
Ex2 - c) (Como Exibição) Mantém a Visão de acordo com o seu respectivo Modelo.

3 ) No MVC entende-se como saída/domínio de dados o M de Modelo. Ex’s:
Ex3 - a) (Como Saída) O Modelo presente na Camada de Cliente sofre uma alteração que também altera algo na Camada de Apresentação;
Ex3 - b) (Como Domínio) O Modelo mantém guardado o dado de quantas vezes o usuário digitou uma tecla em um JTextField;
Ex3 - c) (Como Domínio) O Modelo notifica a sua respectiva visão quando algo é alterado.

4 ) O trio M-V-C forma um triângulo e tem um ciclo/fluxo no formato …->V->C->M->V->C->M->…, formando uma interação circular. Ex:
Ex4 - a) Se a Visão gera um evento o qual é interpretado pelo Controlador como algo que altera o Modelo, após essa alteração, a Visão deve se reenderizar.

5 ) A camada com seu respectivo MVC interage, em uma hierarquia de Camadas, com uma camada superior através da sua Visão e com uma camada inferior através do seu Modelo. Ex:
Ex5 - a) Usuário seleciona uma cor de texto diferente em um componente. Isso é uma interação que ocorre entre o usuário e a Visão da Camada de Cliente. Essa ação do usuário gera uma modificação no Modelo da Camada de Cliente sendo que essa modificação é fruto do resultado de uma solicitação do Modelo da Camada de Cliente à Visão da Camada de Apresentação que retornou ao Modelo da Camada de Cliente.

6 ) A Visão de um MVC lança eventos, e somente eventos crus, ao seu Controlador, o qual interpretará o significado do evento para uma forma legível ao Modelo que poderá ou não ser modificado.

7 ) O Modelo só notificará as Visões que o refletem através de eventos, mas a Visão se atualizará diretamente através da instancia do objeto no Modelo ao qual exibe naquele momento.

8 ) Formulários de preenchimento de dados estão mais para o conceito de MVP do que para o conceito de MVC.

Consegui expor oito pontos na qual a grande maioria parece estar concordando. Preferi me preservar em outros mais discutíveis. Com certeza os próximos post’s serão de usuários discordando desses pontos, mesmo com grande maioria a favor.
Para piorar mais ainda aparece minha avó aqui dizendo que “na casa que falta pão, todos brigam e ninguém tem razão”… o vovó, pega leve poxa!

Bem como disse incialmente o MVC tem muitas ramificações a serem debatidas, as quais acredito que já não são mais suportáveis por este tópico que está imenso.
Sendo assim, vou começar a ramificar também o tópico abrindo novos tópicos com as questões mais “fora de padrão” do padrão MVC, até mesmo para que os novos leitores do tópico se interessem mais com menos sono (Ler 192 postagens com o assunto mudando constantemente dá mais sono que o pós-almoço de Segunda-feira). Vou postando os novos tópicos no início deste principal, para guiar corretamente a galera!

Vou ficar aqui no aguardo das opiniões, principalmente das últimas postagens.
Um abração galera do GUJ, seus usuários e moderadores. Todos proporcionam essa comunidade linda e maravilhosa, a maior do Brasil!

[Lavieri]

7 ) O Modelo só notificará as Visões que o refletem através de eventos, mas a Visão se atualizará diretamente através da instancia do objeto no Modelo ao qual exibe naquele momento.

Só para entender o que exatamente vc esta querendo colocar neste poto, quando fala que o modelo noifica a visão…

A) Se vc esta falando, que um controle, registra uma visão, como observadora do modelo, e este modelo ao ter seu estado alterado, notifica a seus ouvintes (o que indiretamente, e só indiretamente notifica a visão) ai eu concordo.

B) Se vc esta falando, que a propria visão se registra no modelo, ou que o proprio modelo sabe a qual visão alertar ao ter seu estado alterado, ai eu discordo.

Eu acredito que com essa explicação vc quis colocar o ponto “A”, estou apenas tocando neste ponto, para falar sobre a opinião que tenho que o modelo é isolado, ou seja, para colocar o ponto em que o modelo não se comunica com a visão, não diretamente … o modelo tem sim é porta de entrada de informação/eventos, e porta de saida de informação/evento …

essas portas genericas é o que deicham o modelo isolado, e o tornam reutilizaveis, nestes pontos de contato com um mundo exterior vc pode fazer o acoplamento solto com a visão, e esse é o caso “A” que falei aqui.

enfim é isso,

não sei se fui claro com o post, espero que sim

[pedromuyala]

Olá Lavieri! Obrigado por participar! :-o

[quote=Lavieri]A) Se vc esta falando, que um controle, registra uma visão, como observadora do modelo, e este modelo ao ter seu estado alterado, notifica a seus ouvintes (o que indiretamente, e só indiretamente notifica a visão) ai eu concordo.

Eu acredito que com essa explicação vc quis colocar o ponto “A”, estou apenas tocando neste ponto, para falar sobre a opinião que tenho que o modelo é isolado, ou seja, para colocar o ponto em que o modelo não se comunica com a visão, não diretamente … o modelo tem sim é porta de entrada de informação/eventos, e porta de saida de informação/evento …

essas portas genericas é o que deicham o modelo isolado, e o tornam reutilizaveis, nestes pontos de contato com um mundo exterior vc pode fazer o acoplamento solto com a visão, e esse é o caso “A” que falei aqui.[/quote]

Não consigo entender uma coisa:

A) Se vc esta falando, que um controle, registra uma visão, como observadora do modelo …

Como estamos debatendo um assunto Desktop os objetos do trio MVC são instanciados pelo main que é quem liga as partes e o Observer de Model para Visão, certo? Veja:

import javax.swing.JFrame;

public class MVC {
   public static voi main(String args[]) {

      Modelo m = new Modelo();
      Controle c = new Controle(m);
      Visao v = new Visao(c);

      m.addModeloListener(v); // Isso que você está opinando ser o erro?

      JFrame j = new JFrame();
      j.add(v);
      j.setVisible(true);

  }
}

Fico no aguardo pela resposta! Forte abraço.

[Lavieri]

[quote=pedromuyala]

[code]
import javax.swing.JFrame;

public class MVC {
public static voi main(String args[]) {

  Modelo m = new Modelo();
  Controle c = new Controle(m);
  Visao v = new Visao(c);

  m.addModeloListener(v); // Isso que você está opinando ser o erro?

  JFrame j = new JFrame();
  j.add(v);
  j.setVisible(true);

}
}
[/code][/quote]

de forma alguma isso é correto… pois o MAIN é controle, e não modelo… a visão não esta se escrevendo no MODELO, nem o MODELO esta inscrevendo a visao…
o controle é que instancia o MODELO, instancia a VISAO, e pega e junta um no outro… essa abordagem é correta…

o que não pode ?

Modelo { addModeloListener(Visiao v) {} //esse argumento aqui é errado! }

a forma mais correta é

Modelo {
    addModeloListener(ModeloListener ml) {} //ai é correto, aqui vc não conhece a visao
}
//quem precisar que implemente a interface ModeloListener

mas o IDEAL mesmo é

   public static voi main(String args[]) {

      Modelo m = new Modelo();
      Controle c = new Controle(m);
      final Visao v = new Visao(c);

      m.addModeloListener(new ModeloListener() {
           void notificador(ModeloEvento me)  {
              v.façaAlgo();
           }
      });
      JFrame j = new JFrame();
      j.add(v);
      j.setVisible(true);

  }

Observação…

Visao v = new Visao(controller); isso aqui também não é muito bom… não tem motivos para a visão depender do controler, o ideal é vc inverter o papel… deixar o controle cuidar da visão…

[pedromuyala]

mas o IDEAL mesmo é

   public static voi main(String args[]) {

      Modelo m = new Modelo();
      Controle c = new Controle(m);
      final Visao v = new Visao(c);

      m.addModeloListener(new ModeloListener() {
           void notificador(ModeloEvento me)  {
              v.façaAlgo();
           }
      });
      JFrame j = new JFrame();
      j.add(v);
      j.setVisible(true);

  }

Ah sim aí concordo perfeitamente. O Controle do MAIN é quem monta o jogo e quem está fazendo a ligação das notificações do modelo até a visão, está perfeito!

[quote=Lavieri]
Observação…

Visao v = new Visao(controller);

Não entendi como a Visão vai falar com o Controle!
Nesse caso, você diz assim??:

   public static voi main(String args[]) {

      Modelo m = new Modelo();
      Visao v = new Visao();
      Controle c = new Controle(v);

      m.addModeloListener(new ModeloListener() {
           void notificador(ModeloEvento me)  {
              v.façaAlgo();
           }
      });
      JFrame j = new JFrame();
      j.add(v);
      j.setVisible(true);

  }

Fico no aguardo! Abração.

[Lavieri]

o seu main, faz parte do controle… ele é o que monta o inicio da aplicação e da um start…

se o controle que cuida de integrar a visão “v” ao modelo “m” é o controle “c” … então “c” que tem que instanciar e cuidar dos dois …

melhor do que colocar os passos do controle no MAIN é fazer assim

public static voi main(String args[]) { new ControlePrincipal().start(); }

ai no caso o controle principal seria assim…

[code]
public class ControlePrincipal() {

private Modelo modelo;
private ModeloBeanInformacao umBeanContendoInfos;
private Visao visao;

public void start() {
montaModelo();
montaVisao();
ligaAInformacaoDaVisaoComOModelo(); //aqui foi por minha conta, para deixar o exemplo mais rico.
mostraVisao();
}

private void montaModelo() {
this.modelo = new Modelo();
}

private void montaVisao() {
this.visao = new Visao();
modelo.addModeloListener(new ModeloListener() {
void notificador(ModeloEvento me) {
visao.façaAlgo();
}
});
}

private void ligaAInformacaoDaVisaoComOModelo() {
this.umBeanContendoInfos = new ModeloBeanInformacao ()ç
visao.setBeanDeInfos(umBeanContendoInfos);
visao.addVisaoListenerBotaoSalva(new VisaoListenerBotaoSalvar() { //isso é apenas um exemplo didatico
public void botaoClicado(EventoVisaoBotaoSalva evento) {
this.modelo.salvar(evento.getBeanContendoInfos()); //#1
}
});
}

private void mostraVisao() {
visao.setVisible(true); //observação, nesse exemplo, o objeto Visão já é um JFrame,
//se ele não for um, ai vc muda a montagem, ou adiciona um montarJanlea(); antes do mostrarVisao() =P
}
}[/code]

ai o que vc for precisando fazer a mais, vc vai fazendo a ligações com novos controles

no caso ilustrativo do #1 … ai clicar no botão da VIEW, o controle recebe o evento… pega a informação que o modelo precisa do evento (o objeto contendo as informações, esse objeto é um objeto de modelo) … pega este objeto e envia para o this.modelo, para que ele salve o objeto… esse método modelo.salvar(bean); pode disparar um evento, e como a visão esta escutando o evento do modelo, o controle nem precisa se preucupar com a resposta do modelo, pois ela já vai direto pra visão… visto o que foi setado em “montaVisao()” quando adicionou-se a visão como listener…

O papel do controle é esse… intermediar, fazer o meio de campo…

dizer… BOTão da VIEW 1 … vc vai representar tal ação no modelo

ele serve pra isso ocontrole… receber informação dos dois lado… e fazer as ligações… enviar para os lugares corretos

[pedromuyala]

Fala Lavieri, obrigado por continuar aqui atento acompanhando e ajudando no tópico!

Sim realmente é perfeita tanto a explicação quanto a implementação exemplo.
Porque comentou uma linha dizendo que era somente um exemplo didático no código? Eu, na minha opinião, vejo estar perfeito, principalmente quando olho para o desenho teórico do MVC.Interessante é que esse esquema parece ser mais inteligente do que diz a teoria, vou tentar explicar: Na minha opinião esse BEAN solto carrega dados da visão ao controle e do controle ao modelo, ou seja, no caso de preenchimento de formulários, através do evento. Sem falar que posso deixar a visão interativa, assim: o usuário digita um cpf. Na hora que ele sair do campo (tirar o cursor) eu posso lançar um evento que leva o número do cpf até o modelo, que chama as suas camadas inferiores até receber a resposta de volta e notificar a mudança para a visão, no caso de ocorrer, por exemplo um erro ou o cpf já constar.

Fiquei com 3 dúvidas:

1. Como um trio MVC chama outro trio MVC em determinado momento? Assim: Um MVC está ativo. Em determinado momento o usuário clica/seleciona um botão (Ex: JButton “Avançar”) que agora precisa chamar um outro trio MVC (Digamos que ele está trabalhando um trio MVC coeso que trata de pessoas e ao pressionar o botão, agora ele vai ter que mostrar um outro trio MVC coeso que trata de vendas) Consegui expor a dúvida?

2. Se ocorrer um erro/falha nas camadas inferiores e esse deve ser mostrado ao usuário? O Modelo quem terá que ter o atributo para guardar a informação de modo que a visão mostrará assim que o modelo notificar a alteração?

3. Esse BEAN (que é do modelo) não está acoplando tudo a partir do momento que ele é carregado pelo evento?

Mais uma vez muito obrigado Lavieri por estar aqui nos ajudando!
Forte abraço, fico no aguardo pela resposta. E a todos que quiserem colaborar! Não deixe de opinar!

[Lavieri]

[quote=pedromuyala]Fala Lavieri, obrigado por continuar aqui atento acompanhando e ajudando no tópico!

Sim realmente é perfeita tanto a explicação quanto a implementação exemplo.
Porque comentou uma linha dizendo que era somente um exemplo didático no código? Eu, na minha opinião, vejo estar perfeito, principalmente quando olho para o desenho teórico do MVC.Interessante é que esse esquema parece ser mais inteligente do que diz a teoria, vou tentar explicar: Na minha opinião esse BEAN solto carrega dados da visão ao controle e do controle ao modelo, ou seja, no caso de preenchimento de formulários, através do evento. Sem falar que posso deixar a visão interativa, assim: o usuário digita um cpf. Na hora que ele sair do campo (tirar o cursor) eu posso lançar um evento que leva o número do cpf até o modelo, que chama as suas camadas inferiores até receber a resposta de volta e notificar a mudança para a visão, no caso de ocorrer, por exemplo um erro ou o cpf já constar.
[/quote]
didatico, pq assim o é =P … pq estava querendo exemplificar para te explicar =P … just it…

[quote=pedromuyala]

1. Como um trio MVC chama outro trio MVC em determinado momento? Assim: Um MVC está ativo. Em determinado momento o usuário clica/seleciona um botão (Ex: JButton “Avançar”) que agora precisa chamar um outro trio MVC (Digamos que ele está trabalhando um trio MVC coeso que trata de pessoas e ao pressionar o botão, agora ele vai ter que mostrar um outro trio MVC coeso que trata de vendas) Consegui expor a dúvida?[/quote]

a verdade é que não existe TRIO MVC =P … existe o MODELO, a VISAO … e o controlador no meio, fazendo o meio de campo… vc separa em areas lógicas claro… e pode ter vários Controllers…

por exemplo… botão avançar, pode fazer …

new ControleJanelaSeguinte(informacoesPassadasDessaJanela).start(); fechamentoDeRecursos(); //isso aqui se precisar fazer operações e abondonar a janela atual.

um só controle pode cuidar de varias janelas da view, e se comunicar a varias partes do modelo… o ideal é que o controle represente uma operação lógica, ou seja… contenha os caminhos de um case use (quando possivel, para não torar o controle um monstro, vc separa em mais cases o controle)
…

2) Se ocorrer um erro/falha nas camadas inferiores e esse deve ser mostrado ao usuário? O Modelo quem terá que ter o atributo para guardar a informação de modo que a visão mostrará assim que o modelo notificar a alteração?

Normalmente um erro no modelo interrompe um processo que não deveria ser interrompido, as vezes há solução, as vezes não… o modelo quase nunca sabe que decisão tomar, e o que ele faz é enviar a exceção mais pra cima… tem partes do modelo que pode fazer um fluxo de decisão para uma exceção…

vamos ao exemplo…

modelo.salvar(informacao); throws MeuBancoTaOffLineException … o que o modelo pode fazer ?? ficar tentando reconectar ? tentar novamente ? fazer nada ? normalmente aqui não é o lugar de decidir… o que fazer ? essa exceção sai do modelo … ele joga ela pra fora…

o controle é o CARA, ele sabe pra onde vai as coisas

try { modelo.salvar(informacao); } catch(MeuBancoTaOffLineException ex) { mostraJanelaDeDeconectadoEPerguntaSeQuerTentarNovamenteOuReconectarOuEtcs(); }

em alguns casos o erro é de outra ordem

modelo.salvar(informacao); dispara um evento, avisando que não salvou! … e falando que não salvou pq faltou informar um campo… ai alguem pega o evento, e faz com isso o necessário

3) Esse BEAN (que é do modelo) não está acoplando tudo a partir do momento que ele é carregado pelo evento?

ele não ta acoplado a ninguem … ele é um bean, quem o usar, que vai estar se acoplando a ele… a view as vezes tem que realmente conhecer o modelo… quando não dá quando isso é ruim de fazer, ai o controle tem q traduzir esse BEAN pra algo que a VIEW entenda…

mas um BEAN que carrega informação, ele sai de dentro do modelo, com esse intuito, de levar a informação para fora do modelo, que precisar que a use.