MVC (Desktop) - interação!

[Pedro Muyala 0]

Boa Noite! http://forum.imasters.com.br/public/style_emoticons/default/natal_biggrin.gif

 

Há alguns dias, pesquisei muito sobre o MVC (desde sua aplicação no Smalltalk até hoje em aplicações Java). Surgiram, então, dúvidas cruéis sobre a interação das partes na hora de sua implementação (em Desktop / Swing). Observe as a imagem em anexo neste tópico:

Baseado no conceito de: "Desacoplar as partes do MVC de forma que ao precisar trocar ou modificar uma das parte isso não influenciará em modificações nas demais partes, tornando assim o sistema escalável e com maior facilidade de manutenção." Como tornar isso implementável?

 

Como exemplo vamos imaginar um sistema de cadastro qualquer, sem persistencia, dividido em MVC (Modelo, Visão e Controle).

 

Surgem então as perguntas:

1) O main, deverá chamar quem (instaciar): O Controle e/ou a Visão e/ou o Modelo?

2) O Controle interage com quem? (instancia Modelo e/ou Visão?) De que forma?

3) A Visão interage com quem? (instancia Controle e/ou Modelo?) De que forma?

4) Quando o Modelo for alterado, quem vai alterar a Visão? De que forma? (Visão vai instanciar Modelo??? como implementar)

5) Restrições de dados inválidos (tipo inválido de dado para um atributo do modelo) serão bloqueados na Visão?

6) Como estamos baseados em um cadastro, o métodos CRUD ficarão no Controle?

7) Quem vai avisar a Visão se uma das 4 operações do CRUD foi executada com sucesso ou não?

 

Respondida as perguntas, questiono: Olhando agora as respostas, o sistema realmente será implementado no padrão MVC a tal modo de poder a qualquer momento, baseado no conceito citado acima, passa-lo para WEB simplesmente trocando a minha Visão(GUI)?

 

Para fechar, observando as imagens em anexo deixo mais duas perguntas:

8- No View, observa-se a citação "Renderiza o Model". O que é isso?

9) Qual seria o caminho (fluxo) feito pelo sistema de cadastro se eu quiser agora alterar dados que já estão no Modelo?

10) Para um Modelo ser um Bean, ele precisa ter obrigatoriamente um construtor vazio?

 

Felicidades a todos do fórum, sou novo aqui e espero poder compartilhar com todos informações de interesse geral. Um feliz 2009 com bastante saúde e sucesso. Obrigado! http://forum.imasters.com.br/public/style_emoticons/default/natal_happy.gif

[eibon 2]

1) O main, deverá chamar quem (instaciar): O Controle e/ou a Visão e/ou o Modelo?

2) O Controle interage com quem? (instancia Modelo e/ou Visão?) De que forma?

3) A Visão interage com quem? (instancia Controle e/ou Modelo?) De que forma?

O main chama a visão que por sua vez chama o controle que por sua vez chama o modelo.

 

4) Quando o Modelo for alterado, quem vai alterar a Visão? De que forma? (Visão vai instanciar Modelo??? como implementar)

O controlador passa a mensagem para a visão 'em base do que veio do modelo' que por sua vez 'renderiza a imagem' e a mostra para o usuario.

 

5) Restrições de dados inválidos (tipo inválido de dado para um atributo do modelo) serão bloqueados na Visão?

O controle é responsavel por isso.

 

6) Como estamos baseados em um cadastro, o métodos CRUD ficarão no Controle?

Ficarão no modelo (clases Dao serão responsaveis pela persistência de dados).

 

7) Quem vai avisar a Visão se uma das 4 operações do CRUD foi executada com sucesso ou não?

O controle.

 

Respondida as perguntas, questiono: Olhando agora as respostas, o sistema realmente será implementado no padrão MVC a tal modo de poder a qualquer momento, baseado no conceito citado acima, passa-lo para WEB simplesmente trocando a minha Visão(GUI)?

Basicamente...=x

 

8- No View, observa-se a citação "Renderiza o Model". O que é isso?

9) Qual seria o caminho (fluxo) feito pelo sistema de cadastro se eu quiser agora alterar dados que já estão no Modelo?

[1]View envia requests ao controle.

[2]Controle checa os dados.

[3]Controle envia requests ao modelo.

[4]Modelo dá responses ao controle de acordo com os requests feitos pelo controle.

[5]Controle dá responses a view de acordo com os responses recebidos do modelo.

[6]View recebe os responses do controle e os renderiza.

-------------

Modelo[CRUD]

....

----

Exemplo[VIEW]:

Botao novo -> novo formulario -> Botao concluir -> controle(novo(campo1.getText, campo2.getText...))

Botao alterar -> novo formulario -> Botao concluir -> controle(alterar(flag, campo1.getText, campo2.getText...))

Botao deletar -> novo formulario -> Botao concluir -> controle(deletar(flag))

Botao procurar -> novo formulario -> Botao concluir -> controle(pesquisa(flag))

----

[FLUXO]Alterar:

[1]View envia os dados modificados ao controle.

[2]Controle checa os dados modificados.

[3]Controle chama a função de UPDATE do modelo.

[4]Modelo diz ao controle se a operação foi bem sucedida/etc...

[5]Controle formata uma mensagem em base do que o modelo disse a ele.

[6]Controle manda a mensagem a view.

[7]View recebe a mensagem e a renderiza.

 

10) Para um Modelo ser um Bean, ele precisa ter obrigatoriamente um construtor vazio?

Exato.

--------

Dei respostas resumidas devido ao número de questões,mas espero que tenha entendido!

[Pedro Muyala 0]

http://forum.imasters.com.br/public/style_emoticons/default/seta.gif Fala eibon! Muito obrigado pela ajuda e pelo tempo dispensado em ajudar! http://forum.imasters.com.br/public/style_emoticons/default/natal_biggrin.gif

Ah e não foram "respostas resumidas" não, foram as respostas necessárias mesmo, sem muito enfeite!

 

A partir dessas respostas, acabei gerando novas perguntas que ainda são dúvidas para mim. São elas:

 

1) Toda e qualquer comunicação entre a Visão e o Modelo devem obrigatoriamente passar pelo Controle?

2) E se eu tiver duas View diferentes? Serei obrigado a ter dois Controller diferentes?

3) No Modelo vou ter a DAO e o objeto Produto. Sempre que for realizada uma consulta no DAO, essa será carregada no objeto Produto pelo Controlador para depois ir o Controlador mandar para a Visão ou não há necessidade? O Controlador pode mandar direto a consulta para a Visão vinda da DAO? Qual seria esse fluxo?

4) E se for agora o inverso da pergunta 3, invés de consulta, um cadastro? Qual seria esse fluxo?

5) É interessante usar Façade entre a Visão e o Controle? E entre o Controle e o Modelo? Pergunto isso, mas deveria perguntar assim: Como seria a melhor forma de desacoplar o MVC?

6) Quando se diz "Serviço", quer dizer algo semelhante ao BO, porém encapsula regras de negócio para mais de um VO, correto? Ele seria o Controle?

 

Obrigado eibon pela resposta, novamente agradeço, fico no aguardo por mais respostas sua e de todos que quiserem participar conosco! http://forum.imasters.com.br/public/style_emoticons/default/natal_happy.gif

[eibon 2]

1) Toda e qualquer comunicação entre a Visão e o Modelo devem obrigatoriamente passar pelo Controle?

Basicamente.

 

2) E se eu tiver duas View diferentes? Serei obrigado a ter dois Controller diferentes?

Obrigado não.Um controller pode 'cuidar' de várias views.Você passaria a ele uma flag para ele decidir o que fazer (a string cadastrar por exemplo).Mas geralmente é mais organizado e melhor ter vários controllers...

 

 

3) No Modelo vou ter a DAO e o objeto Produto. Sempre que for realizada uma consulta no DAO, essa será carregada no objeto Produto pelo Controlador para depois ir o Controlador mandar para a Visão ou não há necessidade?

Geralmente sim.

 

O Controlador pode mandar direto a consulta para a Visão vinda da DAO?

Poder pode...depende do caso.

 

Qual seria esse fluxo?

[FLUXO]Consulta

[1]View envia dados (flag da selectQuery) ao controlador.

[2]Controlador checa os dadoe se estão ok,passa a flag ao método de consulta da classe xDao.

[3]O método de consulta faz uma consulta em base da flag recebida,cria um objeto da classe x,setando seus atributos como sendo iguais a partes de seu resultSet.

[4]O método consulta retorna esse objeto ao controle.

[5]Controle em base do objeto x recebido formata a mensagem e a envia a view.

[6]View renderiza a imagem recebida.

 

4) E se for agora o inverso da pergunta 3, invés de consulta, um cadastro? Qual seria esse fluxo?

[FLUXO]Cadastro:

[1]View envia dados ao controlador.

[2]Controlador checa os dados e se estão ok,cria um objeto da classe x que posteriormente é enviado ao método de cadastro da classe xDao.

[3]O método da classe xDao cadastra algo em base dos atributos do objeto passado.

[4]Tal método envia uma response ao controle.

[5]Em base da response,controle formata uma mensagem e a envia a view.

[6]View 'renderiza' a mensagem recebida.

 

5) É interessante usar Façade entre a Visão e o Controle? E entre o Controle e o Modelo? Pergunto isso, mas deveria perguntar assim: Como seria a melhor forma de desacoplar o MVC?

Sublyer: o MVC ja é desacoplado...cada camada é separada

 

6) Quando se diz "Serviço", quer dizer algo semelhante ao BO, porém encapsula regras de negócio para mais de um VO, correto? Ele seria o Controle?

Cara...eu não sabia o que era.Procurei na net.E conclui que esse seria o modelo (corrigam-me se estiver errado).

---

Abraço!

[Pedro Muyala 0]

Opa eibon! Mais uma vez obrigado! http://forum.imasters.com.br/public/style_emoticons/default/natal_biggrin.gif

 

Nessas respostas algumas dúvidas surgiram, em alguns itens:

 

5) É interessante usar Façade entre a Visão e o Controle? E entre o Controle e o Modelo? Pergunto isso, mas deveria perguntar assim: Como seria a melhor forma de desacoplar o MVC?

Re: Sublyer: o MVC ja é desacoplado...cada camada é separada

Dúvida: Façade então não se aplica?

 

6) Quando se diz "Serviço", quer dizer algo semelhante ao BO, porém encapsula regras de negócio para mais de um VO, correto? Ele seria o Controle?

Re: Cara...eu não sabia o que era.Procurei na net.E conclui que esse seria o modelo (corrigam-me se estiver errado).

Complemento: Essas duas últimas perguntas (5 e 6) surgiram após eu ter lido este tutorial: Uma proposta MVC para aplicações Desktop (PDF) Não vamos julgar, mas será que a proposta citada é a correta ou regras do MVC estão sendo alteradas?

 

Tem mais dois links sobre MVC interessantes e, na minha opinião, o primeiro é ainda melhor que o segundo. Gostaria da opinião de vocês eles:

Model-View-Controller (MVC) Structure

Criando uma aplicação em 3 camadas (MVC)

 

Obrigado eibon e a todos que estão de alguma forma lendo e tentando ajudar no fórum! http://forum.imasters.com.br/public/style_emoticons/default/natal_happy.gif

[eibon 2]

Nao li o négocio da proposta com total atenção,mas pelo que vi está correto sim,só que ele usa convenções que eu não uso (parecidas talvez...).

O négocio do facade,de DP uso geralmente singleton e factory,de resto,muito raramente.

[Pedro Muyala 0]

Fala eibon, mais uma vez agradeço! http://forum.imasters.com.br/public/style_emoticons/default/natal_biggrin.gif

 

Entendi a sua idéia com o uso do design Factory e do Singleton! O Singleton seria legal usá-lo no Modelo e o Factory para a Visão. Acho que peguei sua idéia!

Legal é que agora ficou bem definido o caminho na hora da implementação, quem instancia quem, quem vai interagir com quem!

 

Qualquer outra dúvida volto a postar! Preciso salientar uma coisa sobre este fórum: A resposta veio de forma muito rápida. http://forum.imasters.com.br/public/style_emoticons/default/natal_tongue.gif Joguei confete!

Um abraço eibon, e convido a todos que quiserem opinar as respostas ou até mesmo responder as questões do primeiro post da forma que imaginam para que fiquem avontade!

[eibon 2]

Opa...belezura!

Mas os 2 seriam no modelo.

[Pedro Muyala 0]

Opa eibon, hahahaha então me desculpe não peguei a idéia! http://forum.imasters.com.br/public/style_emoticons/default/natal_laugh.gif

 

Onde o Factory se encaixaria legal nesse exemplo de cadastro utilizando o MVC?

OQ seria necessário criar ou até mesmo alterar?

 

Um abração! Aguardo pela resposta.

[eibon 2]

Falei que uso geralmente...não que você tem que aplicar (se bem que pelo menos aplicar 1 dos dois é interessante) ou que nesse caso usar as 2 seria legal.

Se usar a singleton nesse caso,pode ser que usar a factory não fique muito legal (vice-versa).

Desculpa se te confundi!

Qualquer uma das 2 fica no modelo. =x

[Pedro Muyala 0]

Opa eibon magina cara, confundiu não! http://forum.imasters.com.br/public/style_emoticons/default/natal_biggrin.gif

E agradeço muito mesmo sua atenção! Vou estudar uma forma de implementar um dos dois. O que melhor se enquadrar!

E que ainda não consegui enxergar em qual momento devo aplicar um dos dois patterns... Mas eu chego lá http://forum.imasters.com.br/public/style_emoticons/default/natal_wink.gif

 

E volto a dizer para todos, quem quiser também responder as perguntas do 1º post será muito bom, amplificaremos o conhecimento deste tópico!!!

[Marcio Leandro 0]

Resumindo isso tudo, o princípio básico do MVC:

 

Model: Se preocupa com as regras de negócio da aplicação. É como alguém que responde uma pergunta, a um nível mais baixo.
View: Se preocupa com a apresentação da informação, a interface com o usuário/sistema.
Controle: Controla as requisições, e toma decisões.

[Pedro Muyala 0]

Olá Marcio, boa noite! Obrigado por estar ajudando! http://forum.imasters.com.br/public/style_emoticons/default/natal_biggrin.gif

 

Então Marcião o conceito do MVC é muito bom, pelo menos ao meu modo de ver, até no entanto adotei ele para tentar entender ao máximo sua real função em desacoplar a aplicação.

Só que quando olhamos só a idéia (isso digo eu) nem imaginava as dúvidas que começariam a surgir na hora de implantá-lo, principalmente como as partes do MVC interagem. Veja esta nova imagem que mostra o conceito de uma forma diferente à imagem do primeiro post deste tópico:

Logo surgem algumas dúvidas, para o desenvolvedor Swing (Desktop):

 

1b) O main vai instanciar quem? Modelo, Controle ou Visão?

2b) O Controle terá domínio total do Modelo e da Visão (ou seja, Modelo e Visão só se falaram através dele)?

3b) Qual a real função do Controle? Quais métodos evidentes ele deverá possuir?

4b) Quem vai validar os dados digitados na Visão com os atributos do Modelo?

5b) O Modelo, é composto de objetos e persistencia, somente?

6b) Em uma consulta à persistencia, os dados deverão ser colocados no objeto para que aí sim o controle os transporte até a Visão? Como seria esse fluxo?

7b) Imaginando um cadastro qualquer, os metódos de inserir/alterar/consultar/deletar (regras de negócio) devem estar no objeto e na DAO também?

8b) Devo usar Façade, singleton ou Factory em que momento? (imaginando um cadastro qualquer)

9b) POJO's aceitam métodos inserir/alterar/consultar/deletar?

10b) Como devo planejar/recursos utilizar no desenvolvimento do MVC de forma a não terminar acoplando tudo novamente?

 

Olhando as respostas, você consegue imaginar agora seu sistema rodando em Web? OQ vou precisar alterar?

 

Acredito que não só eu tenho essas dúvidas ao iniciar a desenvolver JAVA e tentar ao máximo possível seguir uma arquitetura de conhecimento geral da comunidade, até mesmo para manter sempre o sistema com melhor manutenção e escalável.

 

Muito obrigado Márcio pela atenção, espero a resposta aí de todos que puderem colaborar!

Com certeza vai ajudar bastante gente, pelo menos esperamos. http://forum.imasters.com.br/public/style_emoticons/default/natal_happy.gif

[Pedro Muyala 0]

5) Restrições de dados inválidos (tipo inválido de dado para um atributo do modelo) serão bloqueados na Visão?

O controle é responsavel por isso.

 

 

Pessoal, só para que não fiquem dúvidas em aberto, o controle realmente tem esse papel?

Não seria mais interessante deixar a validação no próprio modelo? :unsure:

[scorpio 7]

5) Restrições de dados inválidos (tipo inválido de dado para um atributo do modelo) serão bloqueados na Visão?

O controle é responsavel por isso.

 

 

Pessoal, só para que não fiquem dúvidas em aberto, o controle realmente tem esse papel?

Não seria mais interessante deixar a validação no próprio modelo? :unsure:

 

 

Sim, é o controle.

Não, o model cuida apenas do BD e leva as informações até a view.

 

 

A idéia, é você deixar dependete do banco de dados apenas o model, assim como as validações o controller, e para o "visual" a view.

 

http://forum.imasters.com.br/index.php?showtopic=333693

 

* A View é muda, mas faz gestos (user gestures) para o Controller e escuta mudanças no Model;

* O Model é cego, mas escuta o Controller e fala para a View sobre as mudanças nele próprio;

* O Controller é surdo, fala para o Model quando mudar de estado e vê os gestos da View.

 

[Pedro Muyala 0]

Maravilha Scorpio! Obrigado por estar acompanhando o tópico http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

 

Pesquisando recentemente, descobri (assim como os companheiros já haviam explicado acima) que:

O controle não é "ponte" entre visão e modelo, o controle só existe para receber estímulos da visão (ou seja, quando o usuário mexe na tela), que invoca ações no modelo, nada mais. Quando, por exemplo, for o caso da visão que se renderiza "lendo" o model, não há controle intermediando, o acesso é direto mesmo, e não há nada de errado nisso. Entendam que a premissa do MVC é do modelo não depender da visão, porque este muda frequentemente. Mas o contrário não é verdadeiro, porque o modelo tende a ser mais estável.

Entende-se então que o controle não vai, de forma alguma, dar set's (atualizar algo) na visão. Concorda?

Modelo model = new Modelo();
Visao view = new Visao(model);
Controle control = new Controle(view, model);

Se é assim realmente, tenho algumas dúvidas. São elas:

 

1ª Validar) Quando o controle pegar os dados vindos da visão (jtextfields.getText()) e validar (tipos, tamanho, validarCPF, etc...) se alguns dados não passar na validação, como vou mostrar isso ao usuário, já que a view só se atualiza com base no modelo?

 

2ª Comunicar) Como e Quando a visão saberá que o modelo foi alterado?

 

Agradeço antecipadamente a colaboração, sugestão, opinião ou somente a leitura do tópico! :wink:

Fico no aguardo pelas respostas!

[Pedro Muyala 0]

Olá pessoal, estou aqui novamente (Sete meses de tópico já hein! http://forum.imasters.com.br/public/style_emoticons/default/joia.gif)

 

Bem hoje vim compartilhar os "primeiros passinhos" que estou iniciando em MVC (MVC DESKTOP/SWING)

 

Vou tentar deixar bem claro para a galera conseguir entender a solução. Sendo assim, aí vai:

 

Tenho que fazer um cadastro de cliente com o nome e CPF do cidadão. (Até esse momento vamos ignorar persistencia, validação, etc..).

Até aí simples. Mas como implementar isso na arquitetura do MVC, ou seja, onde cada coisa vai ficar em uma das três letras?

 

Primeira coisa ( :D "coisa"... só rindo mesmo):

1-> Formulário de entrada de dados;

 

No formulário, vamos ter campos JTextField e o botão adicionar (Formulário é Visão "View", procede?):

class ClienteView extends JPanel {   
  
   private JButton botaoCadastrar;   
   private JTextField nome;   
   private JTextField cpf;   
  
   ClienteView() {   
	  nome = new JTextField(10);   
	  add(nome);   
	  cpf = new JTextField(10);   
	  add(cpf);   
	  botaoCadastrar = new JButton("Cadastrar");   
	  add(botaoCadastrar);   
   }   
	 
   public void cadastrar(ActionListener event) {   
	  botaoCadastrar.addActionListener(event);   
   }   
  
   String getCPF() {   
	  return cpf.getText();   
   }   
			   
	void setCPF(String text) {   
	  cpf.setText(text);   
   }   
  
   String getNome() {   
	  return nome.getText();   
   }   
			   
	void setNome(String text) {   
	  nome.setText(text);   
   }   
}

... e no Controle:

public class ClienteControl {   
	   
   private Cliente cli;   
   private ClienteView cv;   
  
	ClienteControl(Cliente cli, ClienteView cv) {   
	  this.cli = cli;   
	  this.cv = cv;   
	  cv.cadastrar(new CadastrarCliente());   
   }   
  
   class CadastrarCliente implements ActionListener {   
	  cli.setCPF(cv.getCPF());   
	  cli.setNome(cv.getNome());   
	  JOptionPane...("Cliente cadastrado");   
   }   
}

E a classe main:

public class Cadastro extends JFrame{   
	 
   Cadastro() {   
	  Cliente cli = new Cliente(); // Este é o bean do Cliente!   
	  ClienteView cv = new ClienteView();   
	  ClienteControl con = new ClienteControl(cli, cv);   
	  add(cv);   
	  setVisible(true);   
   }   
  
	public static void main (String args[]) {   
	  Cadastro cadastrar = new Cadastro();   
   }   
}

Então a pergunta: Essa ligação entre as classes está correta? Existe alguma forma melhor de comunicar Visão c/ Controle e Controle c/ Modelo? :blink:

 

(Volto a deixar claro não quero que as pessoas que estão lendo pensem "ah esse cara quer é que eu faça o código para ele"... não é isso. Eu realmente quero aprender a fazer. Sou sozinho e mesmo com todas as dificuldades luto em tentar entender e aprender. Não quero fazer ninguém de empregado, por favor longe disso!)

Eu particularmente vejo a visão completamente acoplada ao controle (na minha simples e humilde opinião de iniciante).

 

Tenho mais perguntas mas para evitar um monte de pergunta ao mesmo tempo e confundir as pessoas vou aguardar a resposta por esta!

Um abração a todos que vem colaborando com este tópico. Obrigado! http://forum.imasters.com.br/public/style_emoticons/default/bye1.gif