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

Programação Java
#41

Existem centenas de respostas para estas suas perguntas e dentro delas varios “depende”.

Uma coisa que ajuda bastante a “filtrar” a caisa é saber quais são os requisitos do sistema e em que contexto ele será executado.

Não existe uma fórmula única e muitas vezes nem exata para tudo (a tal bala de prata).

Se vc sugerir alguns requisitos e um contexto mais especifico a respeito de suas dúvidas acredito que poderemos fornecer respostas mais objetivas.

Por exemplo:

a) O sistema será client x server e tem tais e tais requisitos.
b) O sistema será web e tais requisitos.
c) Será swing porem poderá acessar um servidor web com tais requisitos.
…

A idéia do padrão MVC poderá mudar mesmo que ligieramente dependendo das opções acima.

flws

#42

Model é o “resto”, o que não é view e nem controller. Beans, Entities, Value Objects, DAOs, Service Locators, Façades… tudo isso é model.

O MVC não diz tudo, não diz como o model deve se comportar, por exemplo. Então, tanto faz (do ponto de vista do MVC) como você faz a persistência.

Sim.

O Controller manda um bean vazio, por exemplo. É ele quem decide.

Observer serve para desacoplar o modelo da visão, não o contrário. Dado dois módulos A e B que precisam trabalhar em conjunto, você só tem duas alternativas: A está acoplado em B mas não o contrário; ou B está acoplado em A mas não o contrário. Não existe essa: “Ah, tanto a view quanto o model estão desacopladas entre si!”. Quem fala isso, não sabe o que diz.

Então, view fica acoplada ao model. Ponto. Já para desacoplar model da view, usa-se Observer no Desktop.

Na web, normalmente, não se faz essa ponta do Observer. Mas pode ser feito, usando técnicas de “AJAX Reverso” que tem por aí.

O que você entende por encapsulamento?

#43

[quote=fantomas]Existem centenas de respostas para estas suas perguntas e dentro delas varios “depende”.

Uma coisa que ajuda bastante a “filtrar” a caisa é saber quais são os requisitos do sistema e em que contexto ele será executado.

Não existe uma fórmula única e muitas vezes nem exata para tudo (a tal bala de prata).

Se vc sugerir alguns requisitos e um contexto mais especifico a respeito de suas dúvidas acredito que poderemos fornecer respostas mais objetivas.

Por exemplo:

a) O sistema será client x server e tem tais e tais requisitos.
b) O sistema será web e tais requisitos.
c) Será swing porem poderá acessar um servidor web com tais requisitos.
…

A idéia do padrão MVC poderá mudar mesmo que ligieramente dependendo das opções acima.

flws

[/quote]

Olá fantomas, desculpa não responder antes passei por alguns problemas familiares, mas resolvidos! :smiley:

Imagine que seja um sistema de mala direta para divulgação de produtos de informática. Essas pessoas vão informar seus dados pessoais no atendimento. Então poderão receber via correio a divulgação do material. Agora esse sistema precisa também poder atualizar o cadastro e até excluir um pessoa na qual não deseja mais receber o informativo. Esses sistema futuramente (após um 1 ano aproximadamente) também disponibilizará um site na Internet na qual a pessoa poderá atualizar seus dados sem precisar ir no atendimento da empresa. Pronto é isso.

Existem 3 computadores do tipo PC. Eles estão conectados por um roteador. Um deles é que tem o programa instalado. Os outros dois chamam pela rede o sistema instalado no servidor. E a tela mostrando os dados de uma mesma pessoa poderá estar aberta nos três computadores ao mesmo tempo.

Fiz perguntas melhores, passando o problema? Ou agora eu compliquei tudo de vez mesmo? :?:
Valew fantomas, obrigado por estar aqui! Abraço. :wink:

#44

[quote=pedromuyala]Olá fantomas, desculpa não responder antes passei por alguns problemas familiares, mas resolvidos!

Imagine que seja um sistema de mala direta para divulgação de produtos de informática. Essas pessoas vão informar seus dados pessoais no atendimento. Então poderão receber via correio a divulgação do material. Agora esse sistema precisa também poder atualizar o cadastro e até excluir um pessoa na qual não deseja mais receber o informativo. Esses sistema futuramente (após um 1 ano aproximadamente) também disponibilizará um site na Internet na qual a pessoa poderá atualizar seus dados sem precisar ir no atendimento da empresa. Pronto é isso.

Existem 3 computadores do tipo PC. Eles estão conectados por um roteador. Um deles é que tem o programa instalado. Os outros dois chamam pela rede o sistema instalado no servidor. E a tela mostrando os dados de uma mesma pessoa poderá estar aberta nos três computadores ao mesmo tempo.

Fiz perguntas melhores, passando o problema? Ou agora eu compliquei tudo de vez mesmo?
Valew fantomas, obrigado por estar aqui! Abraço. [/quote]

Entendi…acho que ficou mais claro; ao menos para mim.

Acredito que vc já falou isto antes, mas só para ter absoluta certeza.

Supondo que as estações (os 2 micros q vc comentou) estejam com a mesma tela, e uma informação presente nesta tela seja alterada; a(s) outra(s) estação(ões) deverão ser atualizada, é isto?

flws

#45

Isso fantomas, exatamente isso! :smiley:

#46

Fala Leonardo, obrigado por estar atento aqui no tópico! :smiley:

[quote=Leonardo3001][quote=pedromuyala]
Persistencia, os métodos ficam escritos dentro dos Beans?[/quote]

O MVC não diz tudo, não diz como o model deve se comportar, por exemplo. Então, tanto faz (do ponto de vista do MVC) como você faz a persistência.
[/quote]
Porque “do ponto de vista do MVC”? Por causa de outras arquiteturas?
Mas e no MVC, geralmente quando entra persistencia em BD, o que mais se usa no seu ponto de vista?

[quote=Leonardo3001][quote=pedromuyala]
A visão reenderiza o bean do Modelo para mostrá-lo. Mas e se a visão for um formulário? Como os dados vão chegar até o modelo?[/quote]

O Controller manda um bean vazio, por exemplo. É ele quem decide.
[/quote]
Desculpa a minha ignorância, eu não entendi. :frowning:
A visão vai carregar os dados informados direto no bean? E pode a visão conhecer o modelo?

Observer serve para desacoplar o modelo da visão, não o contrário. Dado dois módulos A e B que precisam trabalhar em conjunto, você só tem duas alternativas: A está acoplado em B mas não o contrário; ou B está acoplado em A mas não o contrário. Não existe essa: “Ah, tanto a view quanto o model estão desacopladas entre si!”. Quem fala isso, não sabe o que diz.

Então, view fica acoplada ao model. Ponto. Já para desacoplar model da view, usa-se Observer no Desktop.

Na web, normalmente, não se faz essa ponta do Observer. Mas pode ser feito, usando técnicas de “AJAX Reverso” que tem por aí.

O que você entende por encapsulamento?
[/quote]

Por encapsulamento entendo atributos privados de uma classe que só podem ser acessados através de métodos set/get.

Tenho uma dúvida que não sai da cabeça: Se a visão é um formulário na qual recebeu um Bean vazio para ser preenchido a validação de tipos, por exemplo, vai ter que ser feita na VIEW. Imagine: Telefone é um atributo de tipo int. Mas o formulário tem um JTextField. Se o cara digitar caracteres no JTextField do telefone e eu não tratar esse problema é erro na certa.

No meu entender o controle recebe dois objetos: Visão e Modelo. É ele que intermedia OQ vai aparecer na visão e o que vai ser guardado no modelo. É ele quem cuida da validação de dados e tipos. Nele também são tratados os eventos da view. Estou errado?

  • Como deveria ser o fluxo?
  • Quem fala com quem?

Valew Léo, desculpa se estou tendo dificuldades para entender. :frowning:
Posso garantir que estou me empenhando ao máximo para tentar pegar a idéia real do MVC.
Não desista. Peço aos demais também para terem paciência. Tenho certeza que uma hora vou entender, não é possível! Obrigado. :smiley:

#47

Oi pessoal!
Acho que continuo não conseguindo expor o problema de forma que todos entendam, estou errado?
Mas realmente estou iniciando por isso minhas dúvidas são bem básicas. :slight_smile:

Tentei expor a situação do problema nas respostas anteriores. Mas vejo que até o próprio pessoal que vem contribuindo na tentativa de ajudar já está cansando de mostrar soluções boas e o problema continuar. Peço que não desistam e, quem estiver olhando o tópico pela primeira vez que não deixe de dar sua opinião, ajuda, idéia, sugestão ou crítica.
Agradeço antecipadamente a atenção que todos vem dispensando aqui neste tópico. Obrigado mesmo! :wink: :smiley:

#48

Olá pessoal, estou de volta com uma pergunta nova. :smiley:
Li o livro do Deitel (4ªed.) e prestei muita atenção no exemplo do elevador.
Reparei que ele coloca no controle dois JButton que quando acionados alteram alguma coisa na visão do elevador.

Então fico com uma pergunta a ser feita: O formulário para cadastrar uma pessoa no sistema, ou seja, seus JTextField’s (onde entro com os dados da pessoa) e seu JButton (para efetuar o cadastro ao final do preenchimento) devem estar dentro do controle e não na visão, procede? Alguém contra?

Outro detalhe: Ele não usa Observer em nada. Faz uso massivo de Listener’s. Toda comunicação entre o Modelo e a Visão é feito por classes que estão em um pacote denominado por ele “event”. Porque? Qual a vantagem disso em não usar o Observer?

Abraço pessoal novo e antigo que está aqui no tópico já a mais de um mês!
Felicidades a todos. :wink:

#49

Creio que não. Tudo aquilo que representar interface gráfica está na visão. O que o controle recebe são apenas os dados que foram inseridos nos componentes, e não os componentes em si.

Ué, mas um listener é um observer! Quando um listener é registrado para um determinado componente, ele passa a observar os eventos que ocorrem no componente.

#50

Olá tnaires, obrigado em responder!

É realmente é difícil entender né esse MVC. Cada um tem uma resposta diferente não existe um padrão por sí só.
Minha idéia era desenvolver um sistema de forma que qualquer outro programador que fizer manutenção nele tenha como entender de forma fácil, ou seja, perceptível a arquitetura que nele está aplicada. Mas já percebi que é praticamente impossível. kkkkk.
A solução é fazer do jeito que eu entendo ser o melhor jeito, o mais prático, o mais fácil, sem seguir absolutamente nada.
Um abração a todos que ajudaram nesse tópico. Obrigado.

#51

Olhem o exemplo abaixo, acho que isso deixa bem claro a minha dúvida:

"…
Ainda que existam diferentes formas de MVC, o controle de fluxo geralmente funciona como segue:

  1. O usuário interage com a interface de alguma forma (por exemplo, o usuário aperta um botão)
  2. O Controller manipula o evento da interface do usuário através de uma rotina pré-escrita.
  3. O Controller acessa o Model, possivelmente atualizando-o de uma maneira apropriada, baseado na interação do usuário (por exemplo, atualizando os dados de cadastro do usuário).
  4. Algumas implementações de View utilizam o Model para gerar uma interface apropriada (por exemplo, mostrando na tela os dados que foram alterados juntamente com uma confirmação). O View obtém seus próprios dados do Model. O Model não toma conhecimento direto da View.
  5. A interface do usuário espera por próximas interações, que iniciarão o ciclo novamente."

A pergunta: Interface do usuário é diferente de view?
Se sim, então Qual a função da interface do usuário e qual a função da view? Como elas interagem?
Abraço a todos, aguardo resposta nessa última tentativa PQ está difícil.

#52

kkkk… desistiram de mim! Mas mesmo assim valew a todos!

#53

[quote=fantomas][quote=pedromuyala]Olha tenho três computadores em rede. Digamos que o computador 1 faz o papel de servidor. O computador 2 e 3 rodam o aplicativo que está no computador 1.
Nos computadores 2 e 3 estão com a view de um mesmo produto em aberto. Então o computador 3 altera a quantidade do produto e a sua view é atualizada.
Alguém sabe dizer se o computador 2 (lembrando que o aplicativo que está rodando no computador 1 foi implementado com MVC + Observer) vai atualizar a view para a quantidade correta ou computadores 2 e 3 terão view’s com quantidades diferentes? (assim como ocorreria em uma aplicação WEB) [/quote]

Como já disse antes, as vezes não dá ou até não é aconselhavel implementar o padrão na integra; mas vamos lá mesmo assim.

Considerando este seu contexto:

Se o sistema for web:

  1. A máquina 2 executa uma atualização.
  2. Na máquinas 3 haverá apenas PÁGINAS renderizadas pelo navegador e seus scripts (javascript), suas atualizações à principio são baseadas em request / response ou através de um objeto que fica de tempos em tempos executando o que muitos chamam de refresh. Ou seja, o que vc está chamando de view não recebe estimulos de uma coisa chamada controller ou algo do tipo.

Como fazer então: Existe um esquena em AJAX que vc pode incluir no script da página para se tornar um receptor da mensagem enviada pelo server quando ouver alguma atualização. Me parece que o framework ZK já tem uma mecanismo chamado pushing que resolve esta questão.

Se o sistema for swing:

  1. A máquina 2 executa uma atualização.
  2. Na máquina 3 haverá apenas os formulários swing (utilizando mvc) conectado ao servidor (máquina 1); tambem não receberá a atualização do servidor sem ter alguma coisa que fique de tempos em tempos executando uma consulta no servidor.

Como fazer então: Vc poderia utilizar um implementação JMS atrelada ao controller dos formulários da estação; quando o servidor fizer uma atualização ele envia uma mensagem para o client e a atualização será efetuada (é claro que isto é implementado por vc nas rotinas que recebem as mensagens).

É isso ai…o sistema sempre sofre influencia do meio em que será executado.

flws
[/quote]

O que é este tal framework ZK?

#54

http://www.zkoss.org/

flws

#55

Vou tentar deixar bem claro, acho que agora a galera vai conseguir entender a pergunta (MVC DESKTOP/SWING).
Antes de tudo quero também deixar claro que estou com dúvida mesmo e não querendo fazer com que os outros trabalhem para mim ok? Quero aprender mesmo.

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 :lol: (“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?

(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. [color=red]Obrigado![/color] :wink:

#56

Entenderam o post anterior ou estou complicando as coisas? :frowning:
Estou sentindo que o pessoal está querendo me matar… :expressionless:

#57

Xííí esse silêncio está me assustando! :shock:

#58

Oi pedromuyala,

Então…o exemplo que vc descreveu anteriormente está bom na minha opinião, ao menos ficou bem mais organizado do que se fosse tudo misturado, colocado em uma única classe. É claro que este tipo de idéia funciona bem quando vc tem uma quantidade razoavel de campos em um formulário para serem preenchidos.

Você perguntou se dá para fazer melhor que isto. Na minha opinião eu acho que dá mas para isso teria que apelar para um framework que implementa esse padrão (mvc) no swing. Ex. http://www.javaworld.com/javaworld/jw-06-2005/jw-0620-tikeswing.html, tem o genesis https://genesis.dev.java.net/nonav/3.2/maven-site/pt-BR/index.html que é brasileiro e muito bacana também muito embora o ponto central deste framework seja facilitar o desenvolvimento do software em várias partes ele pode ajudar bastante ao implementar o padrão mvc com suas anotações e injeção de dependencia.

Além disso, tem a idéia de que vc não constroi um software apenas com um padrão. Ou seja, dizer que um software web foi construido totalmente utilizando o padrão MVC não transmite um verdade completa na minha opinião porque ao desenvolver vc acaba tendo que aplicar vários padrões. Quanto mais radical for o contexto da aplicação, mais problemas (desafios) aparecem e logo vários outros padrões acabam tendo que ser aplicados.

Implementar totalmente um padrão muitas vezes pode não ser uma boa idéia, tem que ter bom senso e saber aplicar o necessario (estou tentando aprender isso rsrsr) parece que existe o momento certo, a maneira certa e a intensidade correta de se aplicar as coisas; portando muita calma nessa hora.

Este livro http://www.livrariacultura.com.br/scripts/cultura/resenha/resenha.asp?nitem=766140&sid=189859771171634497628532&k5=2C6DF477&uid= (tem em português também) é de um cara que acreditou por um bom tempo que o bom éra aplicar padrões para tudo da “melhor” forma possível e depois mudou de opinião. Neste livro vc verá um “Hello World” que deve ter umas 15 ou 20 linhas, cheio de patterns. O autor chama nossa atenção para o fato de que talvez isso não seja o que queremos e nem o que precisamos. Vale a pena dar uma olhada neste livro, fica aí então a dica.

flws

#59

Olá fantomas, obrigado pela atenção dada aqui ao tópico!

Com certeza muitos padrões provavelmente vão se encaixar no sistema. Gostei muito do artigo do JavaWorld sobre “High-Level MVC”!
O livro a hora que tiver a oportunidade de poder comprar um com certeza vou ler sim!
Como sou iniciante meu entendimento é um pouco mais lento quando leio os artigos mas consigo entender boa parte! :smiley:

Que bom que meus primeiros passinhos de aplicação do MVC estão, na sa opinião, indo bem! Para mim já é um enorme passo!
Então deixa perguntar: Veja o controle (ClienteControl). Após passar os dados da visão para o modelo ele emite um JOptionPane. Gostaria que a mensagem seja mostrada em um JLabel da visão. A visão tem um método “void setStatus(String status);”

Então o novo controle seria:

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());
      cv.setStatus("Cliente cadastrado com sucesso"); // A ÚNICA LINHA QUE MUDOU DO CONTROLE ANTERIOR!
   }
}

Então vem a pergunta: Repare que o controle recebe dados da visão e envia dados para ela também. Não estou acoplando demais visão com controle ou é natural mesmo essa amarração? E só para completar, me deixou curioso: Porque para poucos campos está boa a comunicação? E se fossem uns 50 campos?

Um abração fantomas, obrigadão mesmo cara, está me ajudando muito!

#60

Sim! Neste seu caso o forte acoplamento existe, porque na verdade o que vc fêz foi uma separação de código, uma parte vc chamou de model, outra de view e outra de controller; isto é uma implementação completa do padrão MVC? Eu diria que não por causa de coisas como esta que vc falou, o acoplamento. Mas por que ficou interessante? Porque você deixou o código mais organizado, mais fácil de executar manutenções e introduziu uma estratégia de construir seus códigos o que deixa bem mais fácil de entender o sistema.

No exemplo que vc passou (o último) vc poderia utilizar exceptions para deixar a mensagem dentro da view. Por exemplo, de dentro da view ao clicar no botão confirmar vc executa o código que faz atualização no “controller” e este código por sua vez retorna uma resposta positiva ou negativa atravez de uma exception. Assim vc consegue deixar detalhes que são relacionados a “view”, dentro da view.

Talvez eu tenha cometido um erro ao me expressar, eu quiz dizer que este esquema é bom para vários campos, para poucos talvez não compense muito. Imagine uma janela com 2 campos com nada de muito especial, vc iria criar 3 classes para isto. Será que compensa? Talvez não.

Voltando ao papo do acoplamento, os frameworks para MVC atuam justamente nestas àreas, baixo acoplamento e automatização dos eventos.

flws