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

a camada view serve somente para visualização se você manipular algo la dentro acredito que esteja saindo do padrão MVC.

Mas isso é puro achismo meu

Boa noite.

Não…

A visão “chama” o controle que atualiza o modelo… quando o modelo responder, o controle atualiza a visão… a “ponte” é o controle… ele deve fazer a transformação dos dados de uma camada para a outra… visão é só pra visualização e nada mais… assim você desacopla a lógica de negócios da lógica de visualização…

Abraço,

/spam on

“Tecnólogo em Informática com Ênfase em Gestão de Negócios - FATEC - Mococa - SP”
Mesmo curso que eu to fazendo ;x termino daqui 2 semanas -

/spam off

markin1:

/spam on

“Tecnólogo em Informática com Ênfase em Gestão de Negócios - FATEC - Mococa - SP”
Mesmo curso que eu to fazendo ;x termino daqui 2 semanas -

/spam off

Que é isso? Spam!!! Meu Deus, aqui no nosso GUJ nãããããooooo!!! :shock:

Mais uma simples: Devemos encapsular a visão?

Entendam: Tenho uma tela de cadastro onde os dados são informados em JTextField’s. Esses são atributos privados da classe Visão.
Para o controle recolher o valor dos JTextField’s, devo criar métodos GET/SET, procede?

Obrigado a todos os companheiros que estão colaborando!

Bom ^^ eu crio os Get/Set para os meus campos da classe View.

markin1, que legal que você também está fazendo este curso… ele é muito bom… mas esse negócio de “spam” pegou mal mesmo… rsrsrsrs

Pelas boas práticas, você deve sempre manter os atributos privados (protegidos de acesso externo direto) e criar métodos públicos para atribuir e obter os valores para estes atributos (especificação JavaBeans)… por que assim, você consegue centralizar a lógica para o controle dos valores que podem ser inseridos neles. Imagine um banco… imagine se um um usuário conseguisse acessar o objeto “ContaCorrente” e atribuir o valor saldo diretamente nele: poderia ser um baita de um estrago… mas se você tiver um único ponto de acesso (setSaldo(…), por exemplo) você pode colocar alguma lógica de validação de valores, log de operações, etc… aí… e resolve-se o problema…

Mas direto ao ponto, o controller precisa acessar seus JTextFields através de método publicos… portanto, você deve criá-los… Pesquise sobre encapsulamento para saber mais sobre esta e outras técnicas indispensáveis para o nosso dia-a-dia…

Abraço,

Perfeito ferreira!

Essas duas perguntas fiz realmente para acabar com dúvidas. Muita gente acaba fazendo confusão com elas, até mesmo porque tentam achar uma resposta exata e acabam achando 200 diferentes sobre essas perguntas. Quem quiser dar opiniões diferentes, pode postar! Estamos aqui para aprender e ajudar. :-o

Agora, mais uma simples: E se os métodos da visão mudarem/deixarem de existir, quem vai avisar a equipe do controle? O mesmo pergunto no caso do Modelo :?:

Ninguém mesmo? Nem uma idéia?

Bom dia!

O controle geralmente tem um modo de detectar os métodos da visão através de introspecção/reflection (ele abre o .class e detecta os atributos da view através dos métodos públicos “get e set” dele… então, esta atualização dá-se automaticamente) e quanto ao modelo, você deve projetar bem as interfaces, por que aí você pode mudar a implementação sem mudar a forma de acesso externo… caso haja uma mudança brusca neste ítem, você terá que atualizar todos os componentes que acessam a sua interface, e aí, você poderá ter vários problemas… portanto, novamente: projete bem as interfaces de acesso, por que se precisar alterar o “recheio”, ninguém que utiliza a sua interface ficará sabendo e não sofrerá nenhum problema.

Abraço,

Legal Ferreira, parabéns por estar colaborando!

Mais uma pergunta: E as DAO’s, seram chamadas por métodos no modelo controle ou pelo bean no modelo? :idea:

Desculpem iniciar a discussão bem tarde, mas a definição acima não está correta. 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.

A sim, não sei como se classificam modelo, visão e controle, mas, com certeza, não são camadas.

rodrigo.ferreira:

Pelas boas práticas, você deve sempre manter os atributos privados (protegidos de acesso externo direto) e criar métodos públicos para atribuir e obter os valores para estes atributos (especificação JavaBeans)… por que assim, você consegue centralizar a lógica para o controle dos valores que podem ser inseridos neles. Imagine um banco… imagine se um um usuário conseguisse acessar o objeto “ContaCorrente” e atribuir o valor saldo diretamente nele: poderia ser um baita de um estrago… mas se você tiver um único ponto de acesso (setSaldo(…), por exemplo) você pode colocar alguma lógica de validação de valores, log de operações, etc… aí… e resolve-se o problema…

Mas direto ao ponto, o controller precisa acessar seus JTextFields através de método publicos… portanto, você deve criá-los… Pesquise sobre encapsulamento para saber mais sobre esta e outras técnicas indispensáveis para o nosso dia-a-dia…

Eu sei que essa é a teoria corrente que sustenta a existência dos getters e setters. Mas na prática, os programadores tendem a deturpá-la. Por dois motivos:

1. Métodos que começam com get|set podem até encapsular alguma coisa, mas não são os únicos, porque qualquer método com qualquer padrão de assinatura que manupula atributos privados está encapsulando alguma coisa sobre esse objeto. A vantagem de usar get e set não se sustenta.

2. Por conta de geradores automáticos de getters e setters, as pessoas nunca, mas nunca mesmo, colocam lógica de validação, higienização ou log dentro de um getter ou setter. Pior, para muitos, a alteração de atributos implica na alteração de métodos, o que invalida o encapsulamento.

Resposta rápida:
DAOs são parte do modelo. Simples.

Resposta demorada:
DAOs são parte do modelo, mas, preferencialmente, é melhor eles serem invocados por algum objeto de serviço, que encapsula uma lógica de negócio. Os métodos do objeto de serviço são chamados pelo controle.

Se vc adotar uma abordagem DDD, o Repositorio faz parte do modelo e pode, internamente, usar um DAO para acessar o banco de dados.

Desculpem iniciar a discussão bem tarde, mas a definição acima não está correta. 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.

A sim, não sei como se classificam modelo, visão e controle, mas, com certeza, não são camadas.

Olá Leonardo3001, bem vindo ao tópico!

Rapaz, concordo sim com o que falou e essa era minha ideia inicial. Mas, me tira uma dúvida: Quando a visão vai saber o momento de se renderizar com as mudanças no modelo? Quem vai avisá-la?

Fala Tiago Peczenyj, obrigado por estar colaborando conosco!

Dúvida: Nesse caso, a classe do modelo (Ex. Pessoa.class) que usar banco de dados deverá implementar um método para criação do objeto da classe Repositório?
E como elas se comunicarão?

Abração, aguardo pelas opiniões e sugestões companheiros! :idea:

Nem uma idéia? :idea:
Nada mesmo…

Vamos nos basear em 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.

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 algum 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!
Fico no aguardo pelas respostas!

Ola Pedro, pelo visto temos opiniões diferentes… porém, meu raciocínio é baseado no que uso no dia-a-dia e em obras publicadas de autores conceituadíssimos… como você mesmo disse, se o controle não atualiza a visão, quem avisa a visão de algo não passar na validação:: caímos no conceito de “espaguete” (imagine que você tenha vários servlets que respondem a solicitações de dezenas de JSPs… o que aconteceria se você alterasse uma JSP… você teria que ir em todos os servlets que apontam pra ela e mudar isso manualmente… olha o problema e o risco de erros que você teria… então, centraliza-se tudo no controller, aí, se mudar uma JSP, você muda no controller o resto já fica tudo resolvido… afinal, se pensarmos que o modelo pode atualizar a view sem passar pelo controller, logo percebemos que não precisamos do controller, ou precisamos:: rsrsrs…) . Mas como não sou o dono da verdade, também não digo que o raciocínio dos colegas está errado… apenas diferente… e podem estar certos, dentro de um certo contexto.

Por convenção de obras publicas (é claro que existem divergências), MVC (Model 2 - WEB) se reduz nisto:

Isto é pra web, que uso no dia-a-dia… Quanto à utilização em Swing, creio que seja a mesma coisa, mais não posso afirmar com exata certeza, pois não é a minha especialidade… porém, a sua dúvida presume a conclusão sobre MVC.

Bem, você pode estudar MVC através de vários links:

http://pt.wikipedia.org/wiki/MVC
http://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/

e principalmente aqui: http://java.sun.com/blueprints/patterns/MVC.html (blueprint - Recomendação oficial da Sun Microsystems).

Muito bom o debate… porém, este assunto é muito divergente… e talvez não tenha fim… rsrsrs… portanto, tire uma conclusão própria.

Abraço,

Numa aplicação desktop, a visão muda assim que o model muda, só assim para ter uma consistência. (Imagine seu tocador de MP3, onde a informação de uma música está sendo exibida em duas janelas diferentes. Quando você renomeia o título da música em uma janela, a alteração deve aparecer no mesmo instante na outra janela.) Isso é feito através do padrão Observer, onde seu model é o “observado” que notifica, a quem estiver observando, alguma alteração. O observador é a view, que quando notificado, fara re-renderização da janela (e sem intermédio de controller).

Agora, numa aplicação Web, o que existe é um MVC degenerado, porque as telas NÃO são atualizadas quando ocorre alteração do model (se você consultar um registro numa página, um outro usuário faz update nesse registro e você, depois, não fizer nada, então continuará a ver o mesmo dado antigo na tela).

@Rodrigo

Nunca disse para atualizar model sem passar pelo controller. O que a view poderia fazer diretamente é a consulta, CON-SUL-TA, ao model. Ok?

Outra, imagine uma entidade chamada Produto (model). Aí, quando você consulta, muito provavelmente chamará o controller, que é classe ProdutoAction e método consulta(), certo? Pela lógica do framework, a view será direcionada para /WEB-INF/pages/produto/produto-consulta-ok.jsp, que seria mais ou menos assim:

<p>Produto selecionado: ${produto.nome} <br>Por apenas <span class="preco">${produto.preco}</span></p>

Repare, a view conhece o model, sabe que existe um produto e este tem nome e preco como atributos.

Isso todo mundo faz, mas esquecem que esta é a implicação de que a view conhece o model, manipulando-o apenas para a consulta.

Fala Ferreira, obrigado por continuar atento acompanhando o tópico!
Muito legal a explicação acima sobre MVC e suas variantes!

rodrigo.ferreira:

Isto é pra web, que uso no dia-a-dia… Quanto à utilização em Swing, creio que seja a mesma coisa, mais não posso afirmar com exata certeza, pois não é a minha especialidade… porém, a sua dúvida presume a conclusão sobre MVC.

Essa ficou em aberto agora hein! Já é mais uma nova pergunta para os programadores Java SE!
E o MVC em Desktop, devemos seguir o mesmo para o modelo WEB?
Acredito eu que sim, só que nesse caso usariamos interfaces entre modelo<->controle E modelo<->visão. Estou certo?

Esses links são bons realmente. O primeiro e o última já os conhecia. O segundo foi novidade!

Realmente agradeço Ferreira sua colaboração, espero que continue acompanhando o tópico!
E para todos que estão lendo, respondendo ou não, agradeço antecipadamente pelo tempo utilizado aqui.
E espero por mais sugestões, contradições, visões diferentes, críticas, opiniões, etc.

Ah as perguntas que fiz acima continuam em aberto aguardando mais respostas! Não deixem de dar sua opinião! Obrigado.

Fala Leonardo, parabéns por estar aqui acompanhando o tópico!

Numa aplicação desktop, a visão muda assim que o model muda, só assim para ter uma consistência. (Imagine seu tocador de MP3, onde a informação de uma música está sendo exibida em duas janelas diferentes. Quando você renomeia o título da música em uma janela, a alteração deve aparecer no mesmo instante na outra janela.) Isso é feito através do padrão Observer, onde seu model é o “observado” que notifica, a quem estiver observando, alguma alteração. O observador é a view, que quando notificado, fara re-renderização da janela (e sem intermédio de controller).

Corretíssimo! O padrão Observer. É o que diz também grandes personalidades no mundo java sobre MVC Desktop.
Quero até deixar esse link que mostra um exemplo aplicado.
Não quero ser muito detalhista, mas o Observer usa a única herança disponível que temos na classe. Se for analisar bem, o Observer é o “controlador” entre modelo e visões.
Porque então não não implementar um método simples de atualização na visão na qual o controle chamaria toda vez que ele alterasse algo no modelo? (veja imagem em anexo) Quais problemas isso acaba gerando?

Veja como serão chamadas as classes:

Modelo model = new Modelo(); Visao view = new Visao(model); Controle control = new Controle(visão, modelo); Um problema (com ou sem Observer): Se o usuário do MP3 tentar colocar no nome da música caracteres inválidos. Como o usuário vai ficar sabendo disso, digo, como a visão mostrará o erro?

Leonardo3001:

Agora, numa aplicação Web, o que existe é um MVC degenerado, porque as telas NÃO são atualizadas quando ocorre alteração do model (se você consultar um registro numa página, um outro usuário faz update nesse registro e você, depois, não fizer nada, então continuará a ver o mesmo dado antigo na tela).

Valew galera estarem contibuindo com o tópico!
Com certeza muitos que estão aprendendo estaram se beneficiando com as opiniões!
Obrigado Leonardo por estar conosco!
Não deixem de continuar lendo e participando. Obrigado.

Pedro, bom dia! Agora você chegou no ponto certo!

Diferença principal entre MVC 1 e 2:

“MVC1 it combines the presentation logic with the business logic where as MVC2 it seperates the presentation logic from business logic”

Pronto.

Este “MVC Degenerado” é utilizado, se não por todos, pela grande maioria dos sistemas web feitos em Java; ele é implementado por frameworks como: Struts 1x e 2, JSF (especificação oficial Java EE 5), Webwork, Spring MVC, VRpator etc… e utilizado em praticamente todos os projetos web feitos que em java que você possa usar (bancos, e-commerces, bolsas de valores, seguradoras, setor metalúrgico, de varejo, etc)… e permite o desacoplamento total da visão das outras camadas, logo, você pode facilmente trocar a visão, sem mudar nada no resto; este é o ponto…

Obs: SOA - ESB também utiliza praticamente este mesmo conceito, só que sem a visão (todas as chamadas são centralizadas num controller, e toda a parte de acoplamento é feito nele).

Resumindo: Em aplicações realmente corporativas (Java EE 5 - MVC-2), a visão não sabe nada sobre o modelo, e o modelo não sabe nada sobre a visão, o controle é a “ponte”… você pode utilizar a mesma interface do modelo para aplicações Web, Swing, batch ou até ME… a visão é desacoplada do restante, e isto, pode ter certeza, facilita e muito o trabalho (evitando retrabalho).

No final das contas, você deve utilizar o que se encaixar melhor no seu projeto. O MVC 1 é uma abordagem mais antiga de MVC (quando ainda não existiam muitos sistemas grandes e cheios de componentes), o MVC 2 é uma abordagem mais moderna (baseado no padrão Front Controller - http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html), para descoplar totalmente as camadas (o que não é possível utilizando o padrão Observer - que gera uma total depedência). MVC-2 é o padrão oficial da especificação JEE 5, implementado pelo framework JSF (http://java.sun.com/javaee/javaserverfaces/)

A abordagem de JEE para JSE é diferente, portanto reitero, não sei exatamente como esta abordagem pode ser aplicada em Swing.

A escolha para qual se encaixa melhor no seu projeto é exclusivamente sua…

Abraço,

pedromuyala

Utilizar o padrão MVC em sistemas que envolvem swing + banco de dados ou web NA MAIORIA das vezes é muito difícil de implementa-lo na integra de forma que fique realmente satisfatório; por isso que causa bastante confusão. Porque vc implementa e no final fica aquela sensação de que está faltando alguma coisa ou o que foi feito não está correto.

Na minha opinião os seguintes aspectos complicam a implementação do MVC nestes sistemas (swing + bdo, web e etc… ).

1. Eles necessitam da presença de vários outros padrões além do MVC.
2. Na implementação do MVC existe a tendencia da utilzação do padrão Observer para se chegar na relação entre os 3 pontos (M, V e C) o que pode deixar a aplicação bastante complexa e dificultar muito o entendimento e a manutenção; muito embora alguns recursos tenham sido adicionados pela SUN para ajudar neste sentido.
3. A busca da reação das ações e a baixa dependencia neste padrão muitas vezes gera fluxos bastante confusos.

O ideal seria adotar um framework para ajudar com este padrão, infelizmente para swing não tem muitos e os poucos que tem sempre tem algumas coisas esquisitas, mas é melhor que nada. Sem utilizar frameworks, geralmente é feita a implementação “parcial” do padrão na tentativa de organizar e facilitar as coisas assumindo que há limites.

flws

pedromuyala:

Corretíssimo! O padrão Observer. É o que diz também grandes personalidades no mundo java sobre MVC Desktop.
Quero até deixar esse link que mostra um exemplo aplicado.
Não quero ser muito detalhista, mas o Observer usa a única herança disponível que temos na classe. Se for analisar bem, o Observer é o “controlador” entre modelo e visões.

Não, nem tudo que controla é controlador, pelo menos não para o MVC. O controlador é estritamente para controle de eventos ou de entrada do usuário.

É um simples que acaba saindo caro. Imagine que eu tenha o model M, e eu tenha as views V1, V2 e V3 que a renderizam. Se quem as notificam for o controler C, então seus métodos explicitamente terão que chamar o método de atualização de V1, V2 e V3. Imagine que agora a view V4 também renderizará M, dái você terá que procurar todos os métodos do controler que já manda atualizar as views anteriores para atualizar também a V4. (Pior, e se você esquecer de algum?)

O Observer deixa as coisas meio complicadas a princípio, mas o benefício é que você não polui o Controller com código repetitivo.

Concordo. Quando disse “degenerado”, não quis menosprezar a implementação de MVC pela Web. Todos os frameworks web fazem um MVC “degenerado”, e isso não é nenhum demérito, pois a arquitetura cliente-servidor tem as suas limitações que precisam ser respeitadas.

A view não necessariamente é uma tela para um usuário, pode ser também um XML para consumo externo de outros aplicativos.

Não é. Se a visão não sabe do modelo, como ela se renderiza? Pela adivinhação? O controle sempre repassa o modelo pra view, e a view sempre conhece o model.

Bom dia Leonardo… vamos aumentar um pouco mais o tópico… rsrsrs

Em JEE 5, utilizando MVC com JSF, por exemplo, a JSP conhece um java bean chamado "Managed Bean" (uma Action no caso do Struts 1x), que fica do lado da visão, e nada tem haver com o modelo; a JSP interage única e exclusivamente com este bean (do lado da visão). Este bean faz o "binding", obtendo todos os dados da requisição e devolvendo os dados para o JSP, automaticamente. Ao solicitar dados do modelo, a JSP chama o ManagedBean, que utiliza geralmente os padrões (Business Delegate, Service Locator e Session Facade), encapsulando a chamada para o modelo real... quando o modelo real responder a chamada, então o Business Delegate devolve os dados formatados para o Backing Bean que devolve os dados para o JSP... é um processo um pouco complexo para ser eficazmente explicado aqui.

Um exemplo básico do tutorial oficial da JEE 5 (http://java.sun.com/javaee/5/docs/tutorial/doc/bnaqq.html) seria:

Onde “myForm.jsp” faz binding com o managed bean “myUi.java” e este sim faz a chamada para um Business Delegate que faz o restante do processo…
O ponto aqui é o seguinte: Todo o acoplamento fica encapsulado no Business Delegate; este é o responsável por chamar o modelo real e caso haja alguma alteração neste modelo, é somente com este componente que você precisará se preocupar.

Leonardo, é óbio que é possível chamar o modelo diretamente da visualização, mas isso não é comumente utilizado por questões já citadas nos tópicos anteriores… Estou citando o padrão utilizado em aplicações web corporativas.

Abraço,

rodrigo.ferreira:

Em JEE 5, utilizando MVC com JSF, por exemplo, a JSP conhece um java bean chamado “Managed Bean” (uma Action no caso do Struts 1x), que fica do lado da visão, e nada tem haver com o modelo; a JSP interage única e exclusivamente com este bean (do lado da visão). Este bean faz o “binding”, obtendo todos os dados da requisição e devolvendo os dados para o JSP, automaticamente. Ao solicitar dados do modelo, a JSP chama o ManagedBean, que utiliza geralmente os padrões (Business Delegate, Service Locator e Session Facade), encapsulando a chamada para o modelo real… quando o modelo real responder a chamada, então o Business Delegate devolve os dados formatados para o Backing Bean que devolve os dados para o JSP… é um processo um pouco complexo para ser eficazmente explicado aqui.

Um exemplo básico do tutorial oficial da JEE 5 (http://java.sun.com/javaee/5/docs/tutorial/doc/bnaqq.html) seria:

Onde “myForm.jsp” faz binding com o managed bean “myUi.java” e este sim faz a chamada para um Business Delegate que faz o restante do processo…
O ponto aqui é o seguinte: Todo o acoplamento fica encapsulado no Business Delegate; este é o responsável por chamar o modelo real e caso haja alguma alteração neste modelo, é somente com este componente que você precisará se preocupar.

Leonardo, é óbio que é possível chamar o modelo diretamente da visualização, mas isso não é comumente utilizado por questões já citadas nos tópicos anteriores… Estou citando o padrão utilizado em aplicações web corporativas.

Rodrigo, você mesmo disse: “Ao solicitar dados do modelo, a JSP chama o ManagedBean”, ou seja, o JSP precisa do modelo para renderizar. Não interessa pra view se precisa requisitar o model pro Controller, ou o model é automaticamente injetado nela. O fato é que a view, nos dois casos, conhece o model e, portanto tem dependência dele. E nesse caso, o model ser chamado pela view (não interessa se é direto ou indireto) é bastante comum de ser feito.

O Business Delegate é model, assim como são Service Locator e Service Delegate. Eles têm a função de concentrar alguma regra de negócio ou de acesso, mas não “encapsulam o acoplamento” como você mesmo disse. Coesão e acoplamento são características do sistema como um todo, não dá pra separá-los num módulo do sistema.

Outra, e suas Entities? Elas são parte do model e comumente são retornadas elo Service Delegate. Se houver alguma alteração num getter de uma Entity, as views precisam ser alteradas; o que contradiz sua teoria de que a view é desacoplada do model.

Olá fantomas, boa tarde! Obrigado por estar participando conosco do tópico!

fantomas:

pedromuyala

Utilizar o padrão MVC em sistemas que envolvem swing + banco de dados ou web NA MAIORIA das vezes é muito difícil de implementa-lo na integra de forma que fique realmente satisfatório; por isso que causa bastante confusão. Porque vc implementa e no final fica aquela sensação de que está faltando alguma coisa ou o que foi feito não está correto.

Na minha opinião os seguintes aspectos complicam a implementação do MVC nestes sistemas (swing + bdo, web e etc… ).

1. Eles necessitam da presença de vários outros padrões além do MVC.
2. Na implementação do MVC existe a tendencia da utilzação do padrão Observer para se chegar na relação entre os 3 pontos (M, V e C) o que pode deixar a aplicação bastante complexa e dificultar muito o entendimento e a manutenção; muito embora alguns recursos tenham sido adicionados pela SUN para ajudar neste sentido.
3. A busca da reação das ações e a baixa dependencia neste padrão muitas vezes gera fluxos bastante confusos.

O ideal seria adotar um framework para ajudar com este padrão, infelizmente para swing não tem muitos e os poucos que tem sempre tem algumas coisas esquisitas, mas é melhor que nada. Sem utilizar frameworks, geralmente é feita a implementação “parcial” do padrão na tentativa de organizar e facilitar as coisas assumindo que há limites.

flws

Abração, obrigado por estar participando!
Fico no aguardo pela resposta! Abraço.

Fala Leo, obrigado por continuar aqui discutindo esse assunto, na minha opinião, polemico! kkk.

Leonardo3001:

pedromuyala:

Corretíssimo! O padrão Observer. É o que diz também grandes personalidades no mundo java sobre MVC Desktop.
Quero até deixar esse link que mostra um exemplo aplicado.
Não quero ser muito detalhista, mas o Observer usa a única herança disponível que temos na classe. Se for analisar bem, o Observer é o “controlador” entre modelo e visões.

Não, nem tudo que controla é controlador, pelo menos não para o MVC. O controlador é estritamente para controle de eventos ou de entrada do usuário.

É um simples que acaba saindo caro. Imagine que eu tenha o model M, e eu tenha as views V1, V2 e V3 que a renderizam. Se quem as notificam for o controler C, então seus métodos explicitamente terão que chamar o método de atualização de V1, V2 e V3. Imagine que agora a view V4 também renderizará M, dái você terá que procurar todos os métodos do controler que já manda atualizar as views anteriores para atualizar também a V4. (Pior, e se você esquecer de algum?)

O Observer deixa as coisas meio complicadas a princípio, mas o benefício é que você não polui o Controller com código repetitivo.

Obrigadão Léo por estar acompanhando o tópico, agradeço sem palavras!
Um abração! Não deixe de acompanhar!

Será que não existe um paradigma no MVC entre WEB-SWING?
Ou seja, tenho que fazer dois sistemas mesmo. Um desktop e um web?

Ou posso fazer o sistema desktop no padrão MVC2 citado pelo companheiro Ferreira?
Como ele mesmo deixou em aberto, será que se aplica bem em Desktop?

Não deixe de opinar, criticar, dar sua sugestão, idéia, tudo aquilo que possa benefeiciar o aprendizado de todos aqui do GUJ! :idea:
Com certeza é um assunto polemico não esperava! Mas vai sim beneficiar e ajudar muita gente!
Um abraço a todos que acompanham e desprendem do seu tempo aqui respondendo ou simplesmente lendo o tópico! Obrigado.

pedromuyala:

Concordo com tudo isso aí. Acredito sim que realmente utilizando o Observer estaria implementando uma ótima solução para Desktop.
Tem uma forma (claro, um pouco complexa) de implementar usando Reflection (se não for isso que o Observer faz). Colocaria um método de atualização com o mesmo nome em todas as view’s e ao alterar o modelo, o controle por Reflection identifica as classes de visão e chama o método de atualização. Errado? Pode me corrigir se estou falando bobagem!
Pelo menos economizo a herança da classe. :idea:
Um outro detalhe: E se a visão é uma entrada de dados? E eu tiver várias visões para entrar dados. Como o controle vai “controlar” isso até esses dados chegarem na visão?

O uso de Reflection apenas disfarça as dependências, com ou sem ela, o problema seria o mesmo. O padrão Observer é feito sem reflection.

É mais comum haver várias visões para visualizar dados do que para entrar dados. A razão é que formulários costumam aparecer em janelas modais (que bloqueiam a janela mãe) impedindo uma pessoa de visualizar dois formulários de inserção. Mas não havendo modal, poderia ocorrer de uma tela inadvertidamente atualizar uma outra tela que não deveria. Mas isso é exceção (normalmente queremos a propagação de atualização) e podemos tratar caso-a-caso.

Fala Léo!

Leonardo3001:

O uso de Reflection apenas disfarça as dependências, com ou sem ela, o problema seria o mesmo. O padrão Observer é feito sem reflection.

É mais comum haver várias visões para visualizar dados do que para entrar dados. A razão é que formulários costumam aparecer em janelas modais (que bloqueiam a janela mãe) impedindo uma pessoa de visualizar dois formulários de inserção. Mas não havendo modal, poderia ocorrer de uma tela inadvertidamente atualizar uma outra tela que não deveria. Mas isso é exceção (normalmente queremos a propagação de atualização) e podemos tratar caso-a-caso.

Vamos tantar imaginar um sistema… esses sistemas pequenos de gestão, por exemplo, que estão no comércio (padaria, mercados, lojas, etc) que rodam localmente (Desktop).
Poderia estar até ligado a uma rede local (não deixa de ser Desktop). Concorda comigo que esses sistemas fazem forte uso de cadastro, digo formulários? Produto, cliente, pedidos, etc. Então pergunto: MVC se enquadra ao caso, não? Ou melhor usar MVC2? Se futuramente esses sistema precisar estar disponível na Internet?

Estou pegando um exemplo pequeno para que o novo desenvolvedor entenda melhor o conceito. Senão o assunto começa a ficar muito técnico e interesse do iniciante em aprender.

Já escutei algumas pessoas dizerem que a melhor solução é criar um sistema para a Internet, como a princípio não vai estar na Internet, fazer uma simulação de servidor WEB localmente, ou seja, o usuário já inicia no sistema trabalhando com ele em browser localmente e se no futuro pretender disponibilizá-lo na rede mundial nada precisaria ser alterado! Procede?

Ah pessoal, nem tenho mais palavras para agradecer aí o carinho de todos que estão acompanhando o tópico tentando ajudar de todas as maneiras. :roll:
Muito legal essa discussão, tenho certeza que estará beneficiando muita gente, isso é o mais bacana de tudo! Obrigado a todos.
Fico no aguardo por respostas. Quem não opinou, deu sua sugestão e/ou criticou ainda não tenha medo de estar atrasado! Poste no tópico.

pedromuyala:

Vamos tantar imaginar um sistema… esses sistemas pequenos de gestão, por exemplo, que estão no comércio (padaria, mercados, lojas, etc) que rodam localmente (Desktop).
Poderia estar até ligado a uma rede local (não deixa de ser Desktop). Concorda comigo que esses sistemas fazem forte uso de cadastro, digo formulários? Produto, cliente, pedidos, etc. Então pergunto: MVC se enquadra ao caso, não? Ou melhor usar MVC2? Se futuramente esses sistema precisar estar disponível na Internet?

Na minha opinião pode e deve utilizar MVC.

Depende, as vezes utilizar só páginas pode não ser a melhor solução. Sim, se o sistema já for web facilita muito ao disponibilizar na rede, não importando qual seja.

P.S Normalmente quem diz como o sistema deve ser são os requisitos; devemos evitar ao máximo impor idéias mirabolantes.

flws

Olá fantomas, obrigado por estar acompanhando o tópico!

É acredito que seja melhor desenvolver um sistema já baseado na web mesmo rodando localmente, seguindo o MVC 2… e esquecer o MVC (aquele do Smalltalk).

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)

Agradeço desde já todas as ajudas! São muito bem vindas!

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)

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

Olá fantomas! Estamos aí!

Então, como deve ter notado, não consigo enxergar o uso do padrão Observer.
Vamos tentar agora um exemplo diferente e que com certeza boa parte do pessoal vai entender:

Imaginem um sistema operacional como o Windows (vou pegar o Windows como exemplo, até porque o Linux é muito mais que um simples exemplo kkkk…). Se você está visualizando uma janela (janela nº1) com várias pastas e tiver uma outra janela (janela nº2) exibindo as mesmas pastas da nº1 e resolver deletar uma pasta da nº1 ou nº2 note que as duas janelas (nº1 e nº2) a pasta deletada também some, ou seja, ambas são atualizadas.

Podemos dizer (óbvio que o Windows nem de longe usa tecnologias boas como Java kkkk… Mais uma brincadeirnha! :D) que é um MVC DESKTOP COM OBSERVER?

Note também que se este mesmo caso estiver acontecendo em computadores diferentes ligados em rede (ou seja janela nº1 em uma estação e janela nº2 em outra estação) a atualização ocorre identica a do exemplo anterior citado.

Isso é MVC na camada de apresentação, ou estou enganado?
Valew pessoal, estou no aguardo por respostas! Obrigado.

Olhando por fora parece que sim, o problema é que Observer é apenas o nome de um pattern. Como vc pode chegar no mesmo resultado por outros caminhos fica dificil dizer sem analizar o código utilizado.

pedromuyala:

Note também que se este mesmo caso estiver acontecendo em computadores diferentes ligados em rede (ou seja janela nº1 em uma estação e janela nº2 em outra estação) a atualização ocorre identica a do exemplo anterior citado.
Isso é MVC na camada de apresentação, ou estou enganado?

Eu acredito que sim, talvez a maneira com que foi implementado é que não seja como imaginamos.

flws

Pois então, esse comportamento dos exemplos acima parecem ser bem interessante.

A grande dificuldade, acredito eu, não é entender a teoria mas sim a forma de implementação.
Como separar as coisas!

Veja:
Modelo é só os Beans?
Persistencia, os métodos ficam escritos dentro dos Beans?
E controle, só responde ações da visão?
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?
Como desacoplo visão do modelo? Com Observer em Desktop. Mas e na WEB?
Encapsulamento: Deve ser usada no Modelo, no Controle e na Visão?
Essas são as dúvidas dos iniciantes…

Não deixem de participar respondendo essas perguntas básicas.
Sabemos que para grande parte do pessoal são coisas tão simples que ficam até difícil de responder.
Mas por favor, não deixem essas perguntas em aberto. Obrigado pessoal!

mvc.png576×576

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

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?

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

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.

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.

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

Isso fantomas, exatamente isso!

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

Leonardo3001:

pedromuyala:

Persistencia, os métodos ficam escritos dentro dos Beans?

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.

Leonardo3001:

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?

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?

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.
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.

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.

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!

Olá pessoal, estou de volta com uma pergunta nova.
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.

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.

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.

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.

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

fantomas:

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)

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

O que é este tal framework ZK?

http://www.zkoss.org/

flws

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]

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

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

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

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!

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!

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

Oi fantomas! Nossa cara não sabe como estou feliz de ouvir isso de você! Muito bom!

Poxa que legal a ideia cara! Eu vou estudar direitinho o exception para não postar qualquer coisa aqui de qualquer jeito e assim que conseguir implementá-lo eu volto e mostro como ficou, ok? Não vou sumir e deixar o tópico inacabado.
Também entendi a respeito dos campos… com certeza dou razão no caso de poucos campos é exagero mesmo dividir tanto. Mas para exemplo acho que ficou legal (acredito que você também ache), ainda mais que é um exemplo de cadastro. Mas foi bom notificar isso, até mesmo para os demais usuários iniciantes (como eu) do GUJ ficarem atentos!

Poxa não tenho nem palavras para agradecer pela atenção que está disponibilizando do seu tempo em ajudar. Muito legal mesmo!
Sucesso rapaz, tú merece! [color=red]Obrigadão![/color] Até mais.

Oi fantomas! Como prometido, voltei!

pedromuyala:

fantomas:

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.

Poxa que legal a ideia cara! Eu vou estudar direitinho o exception para não postar qualquer coisa aqui de qualquer jeito e assim que conseguir implementá-lo eu volto e mostro como ficou, ok? Não vou sumir e deixar o tópico inacabado.

Então passei esses últimos quatro dias tentando implementar Exception no código mas infelizmente não consegui. :oops:
Não sei se estou fazendo certo (alias acho que estou fazendo uma bela asneira), até porque nunca trabalhei com exception. Mas não consigo implementar no código do controle, como havia escrito na citação… dá erro na compilação

Veja só as mudanças…

na Visão:

class ClienteView extends JPanel {

   private JButton botaoCadastrar;
   private JTextField nome;
   private JTextField cpf;
   private JLabel lblcad; // JLABEL PARA NOTIFICAR ERRO NO CADASTRO.

   ClienteView() {
      nome = new JTextField(10);
      add(nome);
      cpf = new JTextField(10);
      add(cpf);
      botaoCadastrar = new JButton("Cadastrar");
      add(botaoCadastrar);
      lblcad = new JLabel(); // CRIADO JLABEL PARA NOTIFICAR ERRO!
      add(lblcad); // ADICIONADO AO PAINEL.
   }
   
   public void cadastrar(ActionListener event) { // ALTERAÇÃO DO MÉTODO PARA RECEBER EXCEÇÃO!
      try {
         botaoCadastrar.addActionListener(event);
      }
      catch (Exception e) {
         lblcad.setText("Cliente cadastrado com sucesso!");
   }

   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 { // MÉTODO ALTERADO PARA CRIAR EXCEÇÃO!
      public void actionPerformed(ActionEvent event) throws Exception { // Linha do problema!
         try {
            cli.setCPF(cv.getCPF());
            cli.setNome(cv.getNome());
            throw new Exception();
         }
         catch(Exception e) {
            throw e;
         }
      }
   }
}

No Main nada no código foi alterado mantendo igual!

Mas o problema que ocorre no compilador é o seguinte: ClienteControl.java:13: actionPerformed(java.awt.event.ActionEvent) in ClienteControl.CadastrarCliente cannot implement actionPerformed(java.awt.event.ActionEvent) in java.awt.event.ActionListener; overridden method does not throw java.lang.Exception

Estou fazendo besteira ou será que existe outra forma de fazer a exception para que possa funcionar corretamente?
Tentei várias maneiras diferentes que fui olhando na net mas não estou conseguindo enxergar o erro (como disse, nunca trabalhei com exceptions!).
[color=blue]Obrigado fantomas e todos que estão ajudando![/color]

Estou no aguardo por novas respostas!

Nada mesmo pessoal? Está muito ruim assim? :shock: :oops:

Vc poderia fazer assim:

class ClienteView extends JPanel {

   private JButton botaoCadastrar;
   private JTextField nome;
   private JTextField cpf;
   private JLabel lblcad; // JLABEL PARA NOTIFICAR ERRO NO CADASTRO.

   ClienteView() {
      nome = new JTextField(10);
      add(nome);
      cpf = new JTextField(10);
      add(cpf);
      botaoCadastrar = new JButton("Cadastrar");
      add(botaoCadastrar);
      lblcad = new JLabel(); // CRIADO JLABEL PARA NOTIFICAR ERRO!
      add(lblcad); // ADICIONADO AO PAINEL.
   }
   
   public void cadastrar(ActionListener event) { // Alterei aqui!
       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);
   }

   void displayMsgSucesso() { // Alterei aqui!
         lblcad.setText("Cliente cadastrado com sucesso!");
   }

   void displayMsgErro() { // Alterei aqui!
         lblcad.setText("Erro ao cadastrar o cliente!");
   }
}

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 { 
      public void actionPerformed(ActionEvent event) { // Alterei aqui, este método não espera uma exception.
         try {
            cli.setCPF(cv.getCPF());
            cli.setNome(cv.getNome());

            cv.displayMsgSucesso(); // Alterei aqui

         } catch(Exception e) {

	    cv.displayMsgErro();  // Alterei aqui

            e.printStackTrace();
         }
      }
   }
}

flws

Olá fantomas, boa noite! Desculpa não responder durante a tarde.
Muito legal a idéia de deixar a visão já com os métodos de sucesso/insucesso que são acionados pelo controle através de Exception’s.

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.

Uma simples pergunta: Como dito, frameworks MVC ajudam e muito a minimizar o forte acoplamento. Isso significa que esse último código postado (o que faz uso correto do Exception) ainda pode ser “melhor desacoplado” ou ele já está, no mínimo, satisfatório. Se existe ainda formas de desacoplar (ou seja, torná-lo um MVC real), pode me dar uma dica para que estude o caso :?:

Como havia escrito no primeiro post com código-exemplo, ainda tenho algumas dúvidas mas para não “tumultuar” o tópico com perguntas, assim que se esclarece uma posto a outra. E a pergunta de hoje já é uma dúvida que tenho desde que começei a estudar MVC, que é sobre a validação de dados!
Tentei hoje implementar o que eu consegui entender sobre “validação no modelo do MVC”. Para isso, faço validação do CPF informado. Veja nos códigos abaixo:
[color=orange]* Limpei os comentários antigos, para ficar só os novos! [/color]
Visão

class ClienteView extends JPanel {

   private JButton botaoCadastrar;
   private JTextField nome;
   private JTextField cpf;
   private JLabel lblcad;

   ClienteView() {
      nome = new JTextField(10);
      add(nome);
      cpf = new JTextField(10);
      add(cpf);
      botaoCadastrar = new JButton("Cadastrar");
      add(botaoCadastrar);
      lblcad = new JLabel();
      add(lblcad);
   }
   
   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);
   }

   void displayMsgSucesso() {
         lblcad.setText("Cliente cadastrado com sucesso!");
   }

   void displayMsgErro() {
         lblcad.setText("Erro ao cadastrar o cliente!");
   }

   /* Método para exibição do resultado da validação! */
   void displayCPFErro() {
         lblcad.setText("Erro no CPF do cliente!");
   }
   /* Fim da exibição */

}

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 { 
      public void actionPerformed(ActionEvent event) {
         try {
            cli.setCPF(cv.getCPF());
            
            /* Código de validação do CPF no CONTROLE! */
            if (!Util.validaCPF(cv.getCPF())) { // Util é uma class abstrata e valida o CPF ("true" se validar ou "false" se invalidar).
               cv.displayCPFErro();
               cli.setCPF(null);
            }
            /* Fim da validação */
            else {
               cli.setNome(cv.getNome());
               cv.displayMsgSucesso();
            }
         } 
         catch(Exception e) {
            cv.displayMsgErro();
            e.printStackTrace();
         }
      }
   }
}

Minha pergunta então é: Está visivelmente correto a forma como ficou implementada a validação do CPF? Sempre vou ter que criar métodos com mensagens já prontas na visão para cada situação?
E se eu tiver mais campos para validar, como RG, CEP? Não existe uma forma para que no momento da validação caso ela retorne inválida (false) o try seja interrompido de forma que não chame o método displayMsgSucesso()? Acredito eu que seja gerando uma exceção… mas onde? Na Util? Ou no próprio controle?

Só uma obs: Entende porque perguntei logo no começo sobre o acoplamento? Eu vejo que cada vez mais que o sisteminha vai aumentando o controle vai se acoplando mais à visão. Ou será um engano meu. Que parece dar essa sensação de acoplamento, parece.

Fantomas, rapaz eu estou me sentindo já envergonhado :oops: com a atenção que tem dado ao tópico. Já já você vira as 1000 mensagens no GUJ, está de parabéns. Tenho certeza que muita gente você já ajudou e continua ajudando. Espero com toda certeza ainda um dia saber que se tornou, por exemplo, um moderador do fórum.
Você merece e vai ser com enorme alegria que vou receber essa notícia o dia que se tornar um moderador. [color=red]Obrigado fantomas![/color]

Ninguém arrisca uma opinião? Nem do código nem do acoplamento…

pedromuyala:

Minha pergunta então é: Está visivelmente correto a forma como ficou implementada a validação do CPF? Sempre vou ter que criar métodos com mensagens já prontas na visão para cada situação?
E se eu tiver mais campos para validar, como RG, CEP? Não existe uma forma para que no momento da validação caso ela retorne inválida (false) o try seja interrompido de forma que não chame o método displayMsgSucesso()? Acredito eu que seja gerando uma exceção... mas onde? Na Util? Ou no próprio controle?

Oi Pedro,

Não li todos os seus posts, mas no caso da classe utilitaria eu faria o seguinte:

o método da classe Util que valida o CPF relança uma excesão e não gera log

a camada que chamou recupera a excessão e faz o log

algo parecido

class Util {

   Boolean validaCPF(String cpf) throws ValidationCPFException {

     try {
      //valida
     } catch(Exceptions.... e) {
       // aqui eu handle - trato - todas as excessões possiveis
       throw new ValidationCPFException(VALIDATION_CPF, e.getStackTrace());
     }
   }

class Utiliza {
 
  void metodoValida(String cpf) {

    try {
      Util.validaCPF(cpf);
    } catch (ValidationCPFException v) {
      log.error('erro validando"+e....); 
      // posso deixar correr o erro ou então tentar recuperar o que aconteceu..
    }
  }
}

resumindo, na minha opinião classes utilitárias não devem ser reponsáveis por saber o que fazer quando uma excessão ocorre, elas apenas retornam, pode até retornar um null ou 0, um valor default.. etc
na camada de business, ou outra que utilize a classe, eu só tenho uma excessão do tipo ValidaCPFException.. fica mais facil tratar assim..

[color=blue]Olá André, boa noite![/color] Obrigado por iniciar sua participação aqui no tópico.
Sim legal a idéia, entendi certinho. Para deixar ainda melhor implementei no controle sua ideia para dar continuidade ao código-exemplo. Veja como ficou:

Na Visão, nada mudou.

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 { 
      public void actionPerformed(ActionEvent event) {
         try {

         /* NOVO Código de validação do CPF no CONTROLE! */
            Util.validaCPF(cv.getCPF());
            cli.setCPF(cv.getCPF());
         /* FIM do Código de validação do CPF! */

            cli.setNome(cv.getNome());
            cv.displayMsgSucesso();
         }
         catch (Exception e) {
            cv.displayMsgErro();
            e.printStackTrace();
         }

         /* NOVO Código de validação do CPF no CONTROLE! */
         catch (ValidationCPFException v) {
            cv.displayCPFErro();
         }
         /* FIM do Código de validação do CPF! */

      }
   }
}

No meu entender ficou legal!

:?: Três perguntas ainda estão em aberto:

Em seguida vou postar a próxima pergunta! Enquanto isso se alguém quiser arriscar responder a citada… agradeço. [color=red]Obrigado![/color]

Estou fazendo perguntas sem respostas né?
Acho que estou perguntando “besteiras”.

public class View {
    private Controller controller = null;
    private JButton btnExecute = new JButton("Executar");
    ...
    public View(Controller controller) {
          this.controller = controller;
          this.initialize();
    }

    private void initialize() {
          btnExecute.addActionListener(new ActionListener() {
               View.this.executar();
          });
    }

    private void executar() {
        try {
             this.controller.executar();
              WindowUtil.showMessage("Sucesso ao executar!");
        } catch( Exception e ) {
             WindowUtil.showMessage("Erro ao executar!");
             e.printStackTrace();
        }
    }
}

2) Uma simples pergunta: Como dito, frameworks MVC ajudam e muito a minimizar o forte acoplamento. Isso significa que esse último código postado (o que faz uso correto do Exception) ainda pode ser "melhor desacoplado" ou ele já está, no mínimo, satisfatório. Se existe ainda formas de desacoplar (ou seja, torná-lo um MVC real), pode me dar uma dica para que estude o caso?

Tem esse framework aqui: [url]http://www.javaworld.com/javaworld/jw-06-2005/jw-0620-tikeswing.html[/url].
Tem tambem o genesis (brasileiro): [url]https://genesis.dev.java.net/nonav/3.2/maven-site/pt-BR/index.html[/url], o objetivo principal deste não é implementar o padrão MVC, mas ajuda bastante quem está querendo fazer isto.

Não deixe de ler este conteúdo também: [url]http://java.sun.com/developer/technicalArticles/javase/mvc/[/url]

3) Só uma obs: Entende porque perguntei logo no começo sobre o acoplamento? Eu vejo que cada vez mais que o sisteminha vai aumentando e o controle vai se acoplando mais à visão. Ou será um engano meu? Que parece dar essa sensação de acoplamento, parece.

Reduzir acoplamento nem sempre é simples e pode causar esta impressão mesmo. Mas dá para vc testar o nível de acoplamento de uma forma até simples na minha opinião. Basta vc observar o seu código e fazer as seguintes perguntas para vc mesmo:

1) Eu consigo utilizar este controller em uma outra situação (em um sistema web por exemplo) sem modificar nada?
2) Eu consigo utilizar esta view com um controller que possua comportamentos diferentes?
3) Eu consigo utilizar este model em uma situação bem diferente desta?

Sim for sim para todas estas perguntas significa que vc está no caminho certo.

Lembrando que interfaces são o caminho para um bom desacoplamento, independente de qualquer situação ou padrão; portanto faça uma revisão.

flws

Boa noite fantomas, obrigado mais uma vez em estar acompanhando o tópico.
Legal a última idéia. Dessa forma percebo um desacoplamento geral do controle com a visão e vice-versa, até porque b[/b] o método executar() poderia ter parametros que levariam os dados da visão ao controle. Estou certo? E um detalhe que está fazendo uma enorme diferença é o uso de exceções. Nunca imaginei a importancia das exceções em códigos JAVA.

Vou aproveitar o embalo e colocar mais uma pergunta:b[/b] E se eu precisar informar o usuário na visão do tipo de exceção que ocorreu ao executar o controle nessa nova abordagem apresentada?
Ex: Data inválida -> “Erro: Informe corretamente a data de nascimento!” ou Ex2: “Erro: CPF inválido”. Como o usuário vai saber que só “tal” campo está com problema?
Acredito eu que será com o uso e tratamento de Exceptions, ou não? :shock:

Vou aguardar pela resposta para implementar essa nova abordagem (desacoplamento) no código-exemplo que vinha sendo mostrado. Vou aproveitar também e incluir novos atributos para ficar melhor perceptível a solução.

[color=green][size=16]Muito obrigado galera do GUJ![/size][/color] :thumbup: Aguardo pela resposta, opinião, sugestão, crítica…
fantomas obrigado cara por estar praticamente diariamente respondendo neste tópico e como você diz: flws

Certo.

pedromuyala:

Vou aproveitar o embalo e colocar mais uma pergunta:(2) E se eu precisar informar o usuário na visão do tipo de exceção que ocorreu ao executar o controle nessa nova abordagem apresentada?
Ex: Data inválida -> “Erro: Informe corretamente a data de nascimento!” ou Ex2: “Erro: CPF inválido”. Como o usuário vai saber que só “tal” campo está com problema?
Acredito eu que será com o uso e tratamento de Exceptions, ou não?

Em alguns casos vc consegue retornar resultados sem utilizar exceptions retornando apenas um código ou um valor true ou false; algumas abordagens sugerem vc criar exceptions customizadas quando vc está em um contexto mais complexo como os encontrados em sistemas web, que é bacana também. Quando vc executa uma validação em um controller sem envolver mais nada é mais tranquilo, mas quando a validação ocorre em um servidor muitas podem acontecer, a validação pode retornar positiva, negativa ou pode ocorrer um problema de acesso a base de dados ou até na rede; nestes casos a estratégia de utilizar exceptions pode começar a ficar interessante.

Aqui no forum existem algumas discuções sobre este tema, vê se consegue encontrar.

Lidar com exceptions requer boas práticas, portanto é bom fazer uma pesquisa sobre o assunto; tem bastante na net, eis aqui um link bacaninha: http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html não deixe de lêr e entender.

[]

Olá fantomas, obrigado por continuar acompanhando o tópico!
Maravilha! Vou entender direitinho as exceções antes de fazer as modificações no código.
Uma dica também para quem está atrás de aprender exceções é a revista MundoJava nº36.
Assim que estiver ciente das exceções, volto a postar o código para mostrar como ficou já implementando a nova abordagem sugerida (desacoplamento)!
[color=red]OBRIGADO A TODOS![/color] Não deixem de opinar, criticar…

Olá pessoal do GUJ!
Como prometido, passei esses últimos três dias estudando Exception para tentar chegar a melhor solução cabível no código-exemplo que estamos criando.
Tentei ao máximo possível seguir os conselhos do fantomas e André Fonseca para implementar as Exception. Importante também o artigo deste mês da revista MundoJava no aprendizado. :thumbup:

Vamos ao código-exemplo, que sofreu muita mudança dos últimos exemplos postados, aplicando a nova abordagem (desacoplamento entre visão <-> controle) e o uso de Exception’s.

CLASSES PARA TRATAR EXCEÇÃO:

Superclasse:

public class CadastraException extends Exception {
   
   private String msg;
   
   public CadastraException(String msg) {
      super(msg);
      this.msg = msg;
   }

   public String getMessage() {
      return msg;
   }
}

Subclasse:

public class CPFException extends CadastraException {
   
   public CPFException() {
      super("CPF Inválido");
   }
}

CLASSES DO MVC:

No BEAN CLIENTE (modelo), nada mudou.

Controle:

public class ClienteControl {   
       
   private Cliente cli = null;   
   
   ClienteControl(Cliente cli) {   
      this.cli = cli;   
   }
   
   public void executar(String nome, String cpf) throws Exception {
      try {
         if(!Util.validaCPF(cpf))
            throw new CPFException();
         cli.setCPF(cpf);
         cli.setNome(nome);
      }
         catch(Exception e) {
            throw e;
         }
   }    
}

*OBS: Util.validaCPF(cpf) retorna valor booleano!

Visão:

public class ClienteView extends JPanel {
	 
   private ClienteControl controller = null;
   private JButton btnCadastrar;
   private JTextField nome;   
   private JTextField cpf;   
   private JLabel lblCad; 
 
   public ClienteView(ClienteControl controller) {
      this.controller = controller;
      this.initialize();
   }
   
   private void initialize() {
      nome = new JTextField(10);   
      add(nome);   
      cpf = new JTextField(10);   
      add(cpf);   
      btnCadastrar = new JButton("Cadastrar");   
      btnCadastrar.addActionListener(
             new ActionListener() {
                public void actionPerformed(ActionEvent e) {		     
                  ClienteView.this.executar();
               }
            });
      add(btnCadastrar);   
      lblCad = new JLabel();   
      add(lblCad);   
   }
   
   private void executar() {
      try {
         this.controller.executar(nome.getText(), cpf.getText());
         lblCad.setText("Cadastro realizado com sucesso");
      }
          catch (CadastraException e) {
            lblCad.setText(e.getMessage());
         }
          catch (Exception e) {
            lblCad.setText("Problemas ao cadastrar. Tente novamente!");
         }
   }  
}

main:

public class Cadastro extends JFrame{
   
   Cadastro() {
      Cliente cli = new Cliente(); 
      ClienteControl con = new ClienteControl(cli);
      ClienteView cv = new ClienteView(con);
      add(cv);
      setVisible(true);
   }

    public static void main (String args[]) {
      Cadastro cadastrar = new Cadastro();
   }
}

Reparem que a visão finalmente está (na minha humilde opinião de aprendiz) muito bem desacoplada do controle. O código do controle está mais legível também.

Bem, a minha primeira dúvida com esse novo código é a seguinte: b A hierarquia das classes que compõe as Exception está correta?[/b] (Veja a imagem em anexo!)

Repare que criei uma superclasse CadastraException que é herdada pelas subclasses necessárias para avisar sobre exceções de validações que possam ocorrer durante o cadastro do cliente. Também não descartei a opção de tratar demais exceções que possam ocorrer, como conexão com BD, rede, etc… Repare na visão que se a exceção for de validação ela diz onde ocorreu o erro (qual dado de qual campo gerou uma Exception) e se a exceção for de outro tipo (não conhecido até este momento) só informa com uma mensagem que “ocorreu um problema se possível tente novamente”! (Veja o método [color=blue]executar() na linha 31[/color] do ClienteView). Na imagem exemplo coloquei até uma classe CEPException e OutraException para mostrar a hierarquia. Está correto o procedimento?
O que mais preocupa-me nessa situação é que a mensagem da exceção está sendo tratada fora da visão, o que vai contra o que o fantomas me ensinou em uma postagem anterior quando explicou “que é para deixar detalhes da View dentro da View”. :shock:

A minha segunda dúvida é a seguinte: b A Util.validaCPF(cpf) retorna um valor booleano para o controle que caso seja “false” lança uma CPFException (cria e lança no controle). Eu poderia fazer a Util.validaCPF(cpf) criar e lançar a CPFException() ao invés de retornar um boolean?[/b] Ou seja, aquilo que o André Fonseca propos em uma postagem anterior. (Veja linhas [color=blue]11 e 12[/color] do ClienteControl!)

[color=red]Pessoal[/color], VALE PARA TODOS, não deixem de opinar. Sua opinião/sugestão/crítica é muito importante para manter o tópico vivo e contribuir com todos os companheiros do GUJ!
Se você acredita que algo deve mudar no código-exemplo também não deixe de postar. :idea: E não deixe de selecionar a opção para acompanhar o tópico. Talvés nesse momento não possa ajudar, mas pode surgir uma dúvida que você poderá contribuir!

[size=16][color=green]OBRIGADO GUJ[/color] por proporcionar essa comunidade linda![/size] :arrow: O Brasil inteiro ganha com isso!

Fico no aguardo por novas respostas. Assim que estiver com essas questões solucionadas lançarei nova pergunta para não embolar muitas perguntas com muitas respostas e acabar ficando uma coisa sem começo nem fim, sem lógica entre pergunta e resposta!
Um abraço especial aí para o fantomas, futuro moderador do GUJ, :lol: ele merece!

Eu preferiria estender de RuntimeException, para evitar a lixarada de throws que as checked exceptions precisam.

Outra coisa é que você não está seguindo o princiípio de atirar a exception mais específica, de fora do teu método vai parecer que é tudo Exception. Remova os “throws Exception”

Sobre a segunda pergunta, se quiser que o teu método de checagem também atire uma exception, crie um método tipo validaCPFComException, e deixe o validaCPF em paz. Pelo menos vai ter as duas opções, não se obrigando a fazer ou de um jeito ou de outro.

Olá Bruno Laturner, obrigado por iniciar sua participação no tópico!

Bruno Laturner:

Eu preferiria estender de RuntimeException, para evitar a lixarada de throws que as checked exceptions precisam.

Outra coisa é que você não está seguindo o princiípio de atirar a exception mais específica, de fora do teu método vai parecer que é tudo Exception. Remova os “throws Exception”

Mas e no caso de ocorrer uma exceção, por exemplo, ao conectar-se ao BD, na rede ou uma outra que não conheço?
Se eu remover “throws Exception” do controle (pelo que estou entendendo) teria que substituir por “throws CadastraException”.
Aí como ficariam as exceções que não estendem CadastraException?

Opinem, não deixem de opinar! Fico no aguardo pela resposta!
[color=red]OBRIGADO![/color]

Viraria um throws CadastraException, SQLException, IOException, ParseException, ClassNotFoundException, IllegalAccessException, e outras exceptions…

Vai atirando até vc perceber que a tua classe virou um Mega Zord, e que você está dando responsabilidades demais para ela.

Há um tempo atrás teve uma discussão no arquitetura de sistemas que também conversamos sobre isso. Uma maneira de evitar é saber que as camadas que chamaram o teu código não querem saber o que você está usando, nem as exceções que essas APIs atiram. Converta as exceções de camadas mais abaixo para exceções da sua camada, isso quando forem exceções que você não pode tratar e continuar com a tua vida.

Dito isso, continue a atirar um CPFException, dê um throws CadastrarException, e quando for mudar pro código do cliente, transforme para algum MinhaAplicaçãoException.

Com isso dito, nada te impede de repassar um SQLException ou qualquer outra lá para cima, se essa for a maneira que você trata a tua aplicação. Só há diversas maneiras de fazer a mesma coisa, nenhuma é absoluta.

Olá Bruno, boa noite! Obrigado por continuar acompanhando o tópico!

Viraria um throws CadastraException, SQLException, IOException, ParseException, ClassNotFoundException, IllegalAccessException, e outras exceptions…

Vai atirando até vc perceber que a tua classe virou um Mega Zord, e que você está dando responsabilidades demais para ela.

Há um tempo atrás teve uma discussão no arquitetura de sistemas que também conversamos sobre isso. Uma maneira de evitar é saber que as camadas que chamaram o teu código não querem saber o que você está usando, nem as exceções que essas APIs atiram. Converta as exceções de camadas mais abaixo para exceções da sua camada, isso quando forem exceções que você não pode tratar e continuar com a tua vida.

Dito isso, continue a atirar um CPFException, dê um throws CadastrarException, e quando for mudar pro código do cliente, transforme para algum MinhaAplicaçãoException.

Com isso dito, nada te impede de repassar um SQLException ou qualquer outra lá para cima, se essa for a maneira que você trata a tua aplicação. Só há diversas maneiras de fazer a mesma coisa, nenhuma é absoluta.

Me desculpa mas vamos ver se entendi: No ClienteControl você está me sugerindo para continuar atirando CPFException e fazer o throws de CadastrarCliente? Isso para não quebrar o princípio de atirar a Exception mais específica, correto? Veja o código:

Controle

public class ClienteControl {   
       
   private Cliente cli = null;   
   
   ClienteControl(Cliente cli) {   
      this.cli = cli;   
   }
   
   public void executar(String nome, String cpf) throws CadastraException { // AQUI FOI ALTERADO era: throws Exception
      try {
         if(!Util.validaCPF(cpf))
            throw new CPFException();
         cli.setCPF(cpf);
         cli.setNome(nome);
      }
         catch(CadastraException e) { // AQUI FOI ALTERADO era: catch(Exception e)
            throw e;
         }
   }    
}

Então, a dúvida: Mas e se no try{} do código acima eu tiver uma chamada CliDAO.cadastrar() e ele me retornar uma exceção? Como vou tratá-la?
No CPF eu recebo um boolean e a partir dele gero a exceção correta. Mas e se o restorno for uma exceção, como vou fazer?

Desculpa a minha ignorância Bruno é que realmente sou um aprendiz em JAVA meu conhecimento é mínimo! Tento fazer o possivel para entender lendo tutoriais, artigos mas realmente muitas vezes empaco! Peço desculpa antecipadamente e se puder continuar ajudando, fico muito feliz!

E A TODOS QUE QUISEREM PARTICIPAR, participem! [color=blue]Obrigado.[/color]

Eu me considero um aprendiz também. Acho que vou chegar até o final da vida ainda achando que não sei o suficiente.

Não. Considere como seu código fosse um framework, no sentido que as pessoas utilizam a API do teu aplicativo para poder rodar as coisas delas. O que estou falando é que haverá pelo menos uma exceção genérica da tua aplicação que encapsulará a maioria das outras. Enquanto você estiver dentro da tua própria aplicação, você pode usar as exceções que quiser, em qualquer quantidade, porém esta exceção genérica é mais utilizada para marcar “fronteira entre nações”.

Outro sentido que dou para utilizar “API do teu aplicativo”, é o exemplo da fronteira entre a interface e o núcleo da aplicação, seja a interface web, desktop, webservice, ou outro cliente, o núcleo é sempre o mesmo. Em termos MVC, é a fronteira entre o View+Controller com a do Model.

Note que uma coisa que eu não estou falando é que o cliente deverá se contentar com a exceção genérico, e ficar sem opções. Dá muito bem para descobrir qual foi a exceção específica lançada, desde que não a escondemos. Fala isso por que ainda dá para o teu controller decidir o que ele quer fazer dependendo da exceção lançada.

pedromuyala:

Controle

public class ClienteControl {   
       
   private Cliente cli = null;   
   
   ClienteControl(Cliente cli) {   
      this.cli = cli;   
   }
   
   public void executar(String nome, String cpf) throws CadastraException { // AQUI FOI ALTERADO era: throws Exception
      try {
         if(!Util.validaCPF(cpf))
            throw new CPFException();
         cli.setCPF(cpf);
         cli.setNome(nome);
      }
         catch(CadastraException e) { // AQUI FOI ALTERADO era: catch(Exception e)
            throw e;
         }
   }    
}

Então, a dúvida: Mas e se no try{} do código acima eu tiver uma chamada CliDAO.cadastrar() e ele me retornar uma exceção? Como vou tratá-la?
No CPF eu recebo um boolean e a partir dele gero a exceção correta. Mas e se o restorno for uma exceção, como vou fazer?

1º, remova o try/catch, não servem de nada se você não está tratando alguma coisa.
2º, este código faz parte do model, não do controller. Digo isso por que você está implementando de regras de negócio.

Sobre como tratar, pode fazer do jeito que quiser 8) A pergunta é, o que você quer fazer? Encapsular as exceções em outra? Deixar ela passar? Tratar e tentar se recuperar do que aconteceu? Há algo que você não quer fazer? Não há uma resposta certa, só há decisões, ou pelo menos um objetivo final.

Sobre o código, ele ficaria melhor se você der mais responsabilidade à eles:

public class Cliente
{
  Documento doc;
  String nome;

  ClienteDao dao = DaoFactory.get(Cliente.class);

  public Cliente(Documento doc, String nome)
  {
     this.doc = doc;
     
     if (nome = null)
       throw new IllegalArgumentException("O nome não pode ser nulo.");

     nome = nome.trim();
     if (nome.isEmpty())
       throw new IllegalArgumentException("O nome não pode estar em branco.");

     this.nome = nome;
  }

  public void cadastrar() throws CadastroDeClienteException
  {
     try
     {
       if (dao.jaEstaCadastrado(this))
         throw new ClienteJaCadastradoException();

       dao.cadastrar(this);
     }
     catch (PersistenciaException ex)
     {
       throw new CadastroDeClienteException(ex);
     }
  }
}

public abstract class Documento {}

public class CPF extends Documento {
  String numero;
  public CPF(String numero)
  {
    if(!Util.validaCPF(numero))  
      throw new IllegalArgumentException("CPF inválido.");
    this.numero = numero;
  }
}

[color=blue]Fala Brunão[/color], boa noite! Desculpa a demora para postar a resposta é que precisei ler com calma para entender!
Obrigado por continuar atento ao tópico, sua ajuda está sendo muito importante. Agradeço muito!

Entendi a explicação e também o código. Legal ter criado a classe abstrata Documento, pois assim a classe CPF pode estende-la e futuramente uma classe RG, CNPJ ou qualquer outra relasionada a um documento também poderá. Também gostei muito da separação de responsabilidade nas exceções, ou seja, onde cada uma deve estar!

Como postou anteriormente, arrumei o ClienteControl (controle). Veja como ficou:

Controle

public class ClienteControl {     
         
   private Cliente cli = null;     
     
   ClienteControl(Cliente cli) {     
      this.cli = cli;     
   }   
     
   public void executar(String nome, String cpf) throws CadastroDeClienteException { 
         CPF doc = new CPF(cpf);
         this.cli = new Cliente(doc, nome);
         this.cli.cadastrar();
   }       
}

Modelo: Está a classe Cliente implementada pelo Bruno na sua postagem anterior! NADA ALTERADO!

Visão

import javax.swing.*;
   import java.awt.event.*;

    public class ClienteView extends JPanel {
    
      private ClienteControl controller = null;
      private JButton btnExecute;
      private JTextField nome;   
      private JTextField cpf;   
      private JLabel lblCad; 
   
       public ClienteView(ClienteControl controller) {
         this.controller = controller;
         this.initialize();
      }
   
       private void initialize() {
         nome = new JTextField(10);   
         add(nome);   
         cpf = new JTextField(10);   
         add(cpf);   
         btnExecute = new JButton("Cadastrar");   
         btnExecute.addActionListener(
                new ActionListener() {
                   public void actionPerformed(ActionEvent e) {		     
                     View.this.executar();
                  }
               });
         add(btnExecute);   
         lblCad = new JLabel();   
         add(lblCad);   
      }
   
       private void executar() {
         try {
            this.controller.executar(nome.getText(), cpf.getText());
            lblCad.setText("Cadastro realizado com sucesso");
         }
             catch (CadastroDeClienteException e) {
               lblCad.setText(e.getMessage());
            } 
      }  
   }

Pronto, então a pergunta de hoje: (1) Como a mensagem da exceção que ocorrer no modelo deverá ser mostrada ao usuário na visão?
Ou seja, como o JLabel lblCad de ClienteView vai receber a mensagem [color=blue]“O nome não pode ser nulo.”[/color] caso ela seja lançada no Cliente?
Ou como o mesmo JLabel vai receber a mensagem [color=blue]“CPF inválido.”[/color] caso ela seja lançada na classe CPF?
Lembrando que ambas são [color=red]IllegalArgumentException[/color] e quando ocorrem são mostradas no console!

Outra pergunta: (2) A classe CadastroDeClienteException estende RuntimeException, Exception ou não estende nada? E ClienteJaCadastradoException, estende alguém?

Fico no aguardo pelas respostas, volto a agradecer a todos que estão colaborando. É incrível a magia que o grupo de usuários do GUJ realiza. Só participando mesmo para descobrir. Vejo em todos os posts o esforço do pessoal para tentar chegar a melhor forma de responder as perguntas. Estão todos de parabéns. E não deixem de opinar, mesmo sendo a primeira vez que está lendo o tópico (no primeiro post deixo algumas orientações, se necessário para não se perder no tópico). [color=red][size=18]OBRIGADO GALERA![/color][/size]

pedromuyala:

Pronto, então a pergunta de hoje: (1) Como a mensagem da exceção que ocorrer no modelo deverá ser mostrada ao usuário na visão?
Ou seja, como o JLabel lblCad de ClienteView vai receber a mensagem [color=blue]“O nome não pode ser nulo.”[/color] caso ela seja lançada no Cliente?
Ou como o mesmo JLabel vai receber a mensagem [color=blue]“CPF inválido.”[/color] caso ela seja lançada na classe CPF?
Lembrando que ambas são [color=red]IllegalArgumentException[/color] e quando ocorrem são mostradas no console!

ClienteJaCadastradoException é uma CadastroDeClienteException. Este, por sua vez, pode ser o que você quiser, desde ele seja algo que faça parte da hierarquia de Exception (Throwable para falar a verdade).

[color=red]Boa noite Bruno,[/color] tudo beleza por aí? MUITÍSSIMO OBRIGADO por continuar colaborando com o tópico!

Bruno Laturner:

pedromuyala:

Pronto, então a pergunta de hoje: (1) Como a mensagem da exceção que ocorrer no modelo deverá ser mostrada ao usuário na visão?
Ou seja, como o JLabel lblCad de ClienteView vai receber a mensagem [color=blue]“O nome não pode ser nulo.”[/color] caso ela seja lançada no Cliente?
Ou como o mesmo JLabel vai receber a mensagem [color=blue]“CPF inválido.”[/color] caso ela seja lançada na classe CPF?
Lembrando que ambas são [color=red]IllegalArgumentException[/color] e quando ocorrem são mostradas no console!

Mude os tipos das exceções para alguma do domínio da tua aplicação, ou dê um catch nesse IllegalArgumentException, ou mesmo em Exception. Esses dois últimos não recomentdo.

:arrow: Portanto, vamos ao código-exemplo, na maneira que entendi:
[color=red]OBS IMPORTANTE:[/color] Como ainda não quero entrar na persistencia dos dados, não estou aplicando até este momento nenhuma chamada as classes de persistencia no código-exemplo, limitando o entendimento somente entre a comunicação M-V-C com Exception’s, ok?

MODELO: abstract Documento

public abstract class Documento {}

MODELO: CPF

public class CPF extends Documento {   
      String numero;   
       public CPF(String numero)   
      {   
         if(!Util.validaCPF(numero))     
            throw new CPFException();   
         this.numero = numero;   
      }   
   }

MODELO: Cliente

public class Cliente {
   
      private String nome;
      private Documento cpf;
   
       public Cliente() {
      }
   	
       public Cliente(Documento cpf, String nome)   
      {   
         this.setCPF(cpf);       
         this.setNome(nome);   
      }   
   
       Documento getCPF() {
         return this.cpf;
      }
   			
       void setCPF(Documento cpf) {
         this.cpf = cpf;
      }
   
       String getNome() {
         return this.nome;
      }
   			
       void setNome(String nome) {
         if (nome == null)   
            throw new ClienteException("O nome não pode ser nulo.");   
         nome = nome.trim();
         if (nome.isEmpty())
            throw new ClienteException("O nome não pode estar em branco.");
         this.nome = nome;
      }
   }

CONTROLE:

public class ClienteControl {       
           
      private Cliente cli = null;       
       
       ClienteControl(Cliente cli) {       
         this.cli = cli;       
      }     
       
       public void cadastrar(String nome, String cpf) throws CadastrarClienteException {
         try {      
            CPF doc = new CPF(cpf);
            this.cli = new Cliente(doc, nome);
         }
             catch(CPFException e) {
               throw new CadastrarClienteException(e.getMessage());
            }
             catch(ClienteException e) {
               throw new CadastrarClienteException(e.getMessage());
            }				
      }         
   }

VISÃO:

public class View extends JPanel {
    
      private ClienteControl controller = null;
      private JButton btnExecute;
      private JTextField nome;   
      private JTextField cpf;   
      private JLabel lblCad; 
   
       public View(ClienteControl controller) {
         this.controller = controller;
         this.initialize();
      }
   
       private void initialize() {
         nome = new JTextField(10);   
         add(nome);   
         cpf = new JTextField(10);   
         add(cpf);   
         btnExecute = new JButton("Cadastrar");   
         btnExecute.addActionListener(
                new ActionListener() {
                   public void actionPerformed(ActionEvent e) {		     
                     View.this.cadastrar();
                  }
               });
         add(btnExecute);   
         lblCad = new JLabel();   
         add(lblCad);   
      }
   
       private void cadastrar() {
         try {
            this.controller.cadastrar(nome.getText(), cpf.getText());
            lblCad.setText("Cadastro realizado com sucesso");
         }
             catch (CadastrarClienteException e) {
               lblCad.setText(e.getMessage());
            } 
      }  
   }

ClienteJaCadastradoException é uma CadastroDeClienteException. Este, por sua vez, pode ser o que você quiser, desde ele seja algo que faça parte da hierarquia de Exception (Throwable para falar a verdade).

Exceções: CPFException

public class CPFException extends RuntimeException{
       public CPFException() {
         super("CPF Inválido");
      }
   }

Exceções: ClienteException

public class ClienteException extends RuntimeException {
   
        public ClienteException(String msg) {
         super(msg);
      }
   }

Exceções: CadastrarClienteException

public class CadastrarClienteException extends RuntimeException {
   
       public CadastrarClienteException(String msg) {
         super(msg);
      }
   }

:arrow: OQ EU FIZ: Tentei seguir o conselho de usar RuntimeException no lugar de Exception e de separar “fronteiras entre nações” ([color=blue]Ver linhas vermelhas na imagem em anexo[/color])
Dessa forma, ClienteException trabalha para a classe Cliente e CPFException trabalha para a classe CPF. No controle, como é ele quem transfere os dados da visão para o modelo (cadastra os dados informados nos campos da visão para o BEAN Cliente no modelo) então é encapsulada as mensagens das exceções que aparecerem entre o try{}…catch(){} como CadastrarClienteException. A visão, por sua vez, faz a leitura final de CadastrarClienteException mostrando as mensagens ao usuário, caso elas ocorram.

Agora a pergunta é, com toda humildade do mundo: Estou causando confusão na cabeça dos programadores ou realmente dessa vez ficou certo? Estou fazendo má prática em algum lugar? :shock:

Volto a pedir a todos muita calma e paciência comigo. É uma coisa que estou fazendo todo esforço possível para conseguir entender e não sair por aí vida afora desenvolvendo aqueles famosos códigos que nem o cara que desenvolveu vai entender! Como já havia dito em postagens anteriores eu quero mesmo aprender e não me aproveitar da boa vontade das pessoas que estão ajudando fazendo essas como “empregados”. Pode ter certeza que a sua ajuda aqui será importante não só para mim mas para muitas pessoas que sofrem em entender o padrão MVC.
[size=15]
Obrigado a todos que estão lendo ou tentando ajudar no tópico! Não deixem de opinar, criticar, sugerir… é muito importante sua participação!
Um abração especial aí para o pessoal do GUJ, para os usuários fantomas, Bruno Laturner, André e todos aqueles que postaram também no início do tópico!
[/size]

Antes de começar, uma opinião:

Eu acho um pouco de exagero fazer uma exceção para cada coisa, por mim só atirar um MinhaAplicacaoException bem genérica já resolveria a maioria dos problemas. Não acho que valha a pena criar várias exceções a menos que você vá fazer algo com elas. A especialização é boa quando você precisa tratar casos especiais de forma diferente, que fogem à regra de tratamento da exceção principal. Não é isso que temos ainda.
Com isto dito, vamos continuar com o que já foi feito.

Fazendo todas elas estender diretamente de RuntimeException faz com que você tenha que dar um catch RuntimeException para pegar todos de maneira uniforme. Isso não é bom.

package minhaaplicacao.exception;

public class MinhaAplicacaoException extends RuntimeException
{
    public MinhaAplicacaoException() {
        super();
    }

    public MinhaAplicacaoException(String message) {
        super(message);
    }

    public MinhaAplicacaoException(Throwable cause) {
        super(cause);
    }

    public MinhaAplicacaoException(String message, Throwable cause) {
        super(message, cause);
    }
}

private void cadastrar() {
         try {
            this.controller.cadastrar(nome.getText(), cpf.getText());
            lblCad.setText("Cadastro realizado com sucesso");
         }
             catch (MinhaAplicacaoException e) {
               lblCad.setText(e.getMessage());
            } 
      }

Eu tinha mais umas coisas pra falar, mas o sono está atrapalhando a organizar as idéias hehe. ^_^ ;O

Opa Bruno… magina cara não quero atrapalhar seu sono!
Mas fiquei curioso com a frase final que avisou! Fico no aguardo, abração!

Acho que era só isso mesmo.

Quando for atirar uma nova exceção a partir de outra, use os construtores da classe que recebem um Throwable, ao invés de mandar só a String com uma mensagem. Daí dá para saber de onde veio a exceção.

Na maioria dos casos eu preferiria deixar a exceção se propagar até o final, sem encapsular uma dentro da outra. Não dou um catch quando não tenho nada para fazer com a exceção. Polui menos o código também.

Fala Bruno, beleza, boa tarde!
Acho que agora sim eu entendi a essência da Exception! Ou seja, CPFException, ClienteException, OutraExeption… estendem MinhaAplicacaoException e no controle, no método cadastrar(), eu deixo só o throws MinhaAplicacaoException para passar até a visão e aí sim finalmente uso o try{}… catch(){} para colocar a mensagem no JLabel. É isso? Agora acertei? :roll: Por favor Bruno, não deixe de confirmar se é isso mesmo para que eu possa implementar e mostrar o código aqui para todos. [color=red]Obrigadão Bruno, fico no aguardo[/color]!

É isso mesmo.

O próximo passo é tratar erros que você não esteja esperando.

Tente lançar de propósito RuntimeException que não seja um MinhaAplicaçãoException, lá de dentro do model, para ver o comportamento da aplicação quanto à essas exceções.

Opa Bruno, é o Pedro. [color=olive]Fiz como mandou e realmente ficou 100% a implementação![/color]
Antes de postar o código, vou responder a pergunta que me fez:

A exceção apareceu no console e não na visão. Até entendi o porque pois essa throw new RuntimeException("…"); no modelo não estende a classe MinhaAplicacaoException.

Vixe, mas e agora… como vou tratar as exceções (erros) que não conheço?

Já sei que não é para ficar atirando qualquer coisa senão vou acabar criando um Mega Zord Exception no método do controle. :lol: Mas a princípio acredito que não vou poder ficar mostrando na visão qualquer tipo de exceção que vier das camadas de baixo nível até para que não apareçam mensagens que um simples usuário do sistema não vai entender. Ex: NullPointerException, RuntimeException ou qualquer outra que estende a classe Exception. Porém não posso simplemesmente ignorar o erro pois aí estaria cometendo uma “infração de sete pontos na carteira”, principalmente nas Exception’s checadas. Imaginem o problemão caso ignore uma SQLException na hora de cadastrar um cliente… Acredito eu que agora sim vai entrar uma espécie de encapsulamento ou voltei a falar abobrinhas? Desculpem se for o caso. :oops:

Mas estou ficando muito feliz! Até porque é a primeira vez que estou entendendo como escrever códigos de forma legível ao mundo dos javeiros.
Realmente é muito legal a magia do Java quando bem escrito, bem estruturado!

[size=15]Fico no aguardo pela resposta. Volto a agradecer a todos que estão acompanhando o tópico, sejam os veteranos como os novos, e ao pessoal do GUJ que mantém essa comunidade maravilhosa! Volto a dizer, sei que estou sendo repetitivo, mas não deixe de opinar, sugerir mudanças, criticar, perguntar, doar idéias, reclamar… enfim tudo aquilo que possa colaborar com o tópico. Tenho a absoluta certeza que muita gente, principalmente o pessoal novo na linguagem JAVA estará aprendendo muito aqui.[/size] :thumbup:

Um abração para todos, [color=blue][size=15]OBRIGADO![/size][/color]

Ninguém mesmo? Mas fico no aguado.

Exceções que você não conhece são as unchecked, Errors ou RuntimeExceptions. Errors não tem muito o que fazer a não ser fechar o programa(e tentar logar o erro). RuntimeExceptions geralmente são erros de programação, também o que dá para fazer é logar a exceção e dar desculpas.

Em ambos os casos você se previne escrevendo bons códigos com boas práticas.

Fala Brunão, boa tarde!

Então se ocorrer um erro/exception que por ventura venha ocorrer e não estende MinhaAplicacaoException, no máximo, deve ser logado e só?

Bruno, você acha que estou fazendo certo o MVC se comunicar através de Exceções?

Eu gostei da idéia porque todas as letras do (M-V-C) interagem sem precisar instanciar uma a outra. Até aí, legal, afinal: É um cadastro. Ou seja, a informação transita da visão -> controle -> modelo. Se algum problema ocorre nesse meio (Exception) ela facilmente chega a visão.

Mas e se eu fizer uma busca que retornara clientes? Aí o fluxo é invertido (visão <- controle <- modelo). Não vou trazer informações do modelo até aparecer na visão através de Exception’s, estou errado?

Obrigado Bruno, fico no aguardo pela resposta!

pedromuyala:

Fala Brunão, boa tarde!

Então se ocorrer um erro/exception que por ventura venha ocorrer e não estende MinhaAplicacaoException, no máximo, deve ser logado e só?

Bruno, você acha que estou fazendo certo o MVC se comunicar através de Exceções?

Eu gostei da idéia porque todas as letras do (M-V-C) interagem sem precisar instanciar uma a outra. Até aí, legal, afinal: É um cadastro. Ou seja, a informação transita da visão -> controle -> modelo. Se algum problema ocorre nesse meio (Exception) ela facilmente chega a visão.

Mas e se eu fizer uma busca que retornara clientes? Aí o fluxo é invertido (visão <- controle <- modelo). Não vou trazer informações do modelo até aparecer na visão através de Exception’s, estou errado?

Obrigado Bruno, fico no aguardo pela resposta!

[color=red]Opa pessoal, estou postando o código já implementado (qua havia prometido) já com as exceções para ficar viável o entendimento da pergunta acima.[/color]

Classes do Modelo: [abstract Documento, Cliente e CPF]

abstract Documento:

public abstract class Documento {}

CPF:

public class CPF extends Documento {   
      String numero;   
       public CPF(String numero)   
      {   
         if(!Util.validaCPF(numero))     
            throw new CPFException();   
         this.numero = numero;   
      }   
   }

Cliente:

public class Cliente {
   
      private String nome;
      private Documento cpf;
   
       public Cliente() {
      }
   	
       public Cliente(Documento cpf, String nome)   
      {   
         this.setCPF(cpf);       
         this.setNome(nome);   
      }   
   
       Documento getCPF() {
         return this.cpf;
      }
   			
       void setCPF(Documento cpf) {
         this.cpf = cpf;
      }
   
       String getNome() {
         return this.nome;
      }
   			
       void setNome(String nome) {
         if (nome == null)   
            throw new ClienteException("O nome não pode ser nulo.");   
         nome = nome.trim();
         if (nome.isEmpty())
            throw new ClienteException("O nome não pode estar em branco.");
         this.nome = nome;
      }
   }

Classe do Controle:

public class ClienteControl {       
           
      private Cliente cli = null;       
       
       ClienteControl(Cliente cli) {       
         this.cli = cli;       
      }     
       
       public void cadastrar(String nome, String cpf) throws CadastroDeClienteException {
         CPF doc = new CPF(cpf);
         this.cli = new Cliente(doc, nome);
      }
   }

Classe da Visão:

import javax.swing.*;
   import java.awt.event.*;

    public class View extends JPanel {
    
      private ClienteControl controller = null;
      private JButton btnExecute;
      private JTextField nome;   
      private JTextField cpf;   
      private JLabel lblCad; 
   
       public View(ClienteControl controller) {
         this.controller = controller;
         this.initialize();
      }
   
       private void initialize() {
         nome = new JTextField(10);   
         add(nome);   
         cpf = new JTextField(10);   
         add(cpf);   
         btnExecute = new JButton("Cadastrar");   
         btnExecute.addActionListener(
                new ActionListener() {
                   public void actionPerformed(ActionEvent e) {		     
                     View.this.cadastrar();
                  }
               });
         add(btnExecute);   
         lblCad = new JLabel();   
         add(lblCad);   
      }
   
       private void cadastrar() {
         try {
            this.controller.cadastrar(nome.getText(), cpf.getText());
            lblCad.setText("Cadastro realizado com sucesso");
         }
             catch (CadastroDeClienteException e) {
               lblCad.setText(e.getMessage());
            } 
      }  
   }

Classes de Exceções: [CadastroDeClienteException, ClienteException e CPFException]

CadastroDeClienteException:

public class CadastroDeClienteException extends RuntimeException {
    
       public CadastroDeClienteException() {   
         super();   
      }   
   
       public CadastroDeClienteException(String message) {   
         super(message);   
      }   
   
       public CadastroDeClienteException(Throwable cause) {   
         super(cause);   
      }   
   
       public CadastroDeClienteException(String message, Throwable cause) {   
         super(message, cause);   
      }   
   }

ClienteException:

public class ClienteException extends CadastroDeClienteException {
   
       public ClienteException(String msg) {
         super(msg);
      }
   }

CPFException:

public class CPFException extends CadastroDeClienteException {
       public CPFException() {
         super("CPF Inválido");
      }
   }

[size=16]A pergunta é a citada nesta mensagem.[/size]
Agradeço a todos do GUJ que estão ajudando e colaborando com o tópico!
Agradeço também aqules que disponiblizam de seu tempo simplesmente lendo o tópico e mesmo não postando, de alguma maneira, tentou ajudar!
Não deixe de opinar, dar sugestões, criticar… [color=orange][size=20]OBRIGADO![/size][/color]

Meu Deus esse silêncio me assusta! :shock:
Devo estar fazendo perguntas sem sentido…

Pessoal se estiver existindo alguma dificuldade para entender a pergunta por favor não deixem de avisar que eu tento expor melhor o problema para vocês.
Qualquer coisa também se preferir mandar a pergunta por MP pode mandar.
Peço antecipadamente desculpa se estou formulando mal a pergunta…é que realmente tenho muita dificuldade às vezes até para formular as perguntas.
Não me levem a mal… qualquer situação de dúvida pode falar!
Obrigado pessoal, um abraçopara todos e para o Bruno que me ajudou bastante nessas últimas postagens. Sucesso!

Boa Tarde pessoal!

Sério mesmo que não existe nada na qual possa me ajudar para resolver o caso?
Nada mesmo, uma dica, uma opinião, uma pergunta, uma crítica…??? :oops:
Ou estou pedindo algo impossível e insustentável???
Que vontade de chorar…

Não, vc não está errado! Vc não vai utilizar exceptions para transportar dados.

visão <- controle <- modelo

A idéia do padrão MVC tem que ficar isolado no cliente sem envolver diretamente o servidor ou outro tipo de coisa. Significa que o controle é quem irá executar qualquer ação externa ao módulo (MVC).

Existe uma variação desta idéia chamada MVP, dá uma lida no conteúdo deste link http://www.javafree.org/artigo/871446/Apresentando-ModelViewPresenter-o-MVC-focado-na-visualizacao.html.

flws

Fantomas, boa tarde! Desculpa na demora ao responder!
Mais uma vez muitíssimo obrigado por continuar atento ao tópico, sem palavras!

Vou implementar neste final de semana o exemplo do artigo com calma e volto a postar!
Um abração!

Pedro, dê uma lida no Mundo Java nº 36 que saiu este mês, nele tem um artigo do Eduargo Guerra que resume exatamente o que explicamos aqui sobre exceções. É bem mais claro e diz algumas coisas que não falamos aqui.

Olá Bruno, boa tarde!
Obrigado pela indicação mas eu já havia visto a matéria do Eduardo. Até cheguei a dizer em posts anteriores indicando para quem estivesse também interessado para ler!

Ainda estou tentando entender o MVC. Ainda tenho muitas dúvidas que, ao meu ver são perguntas simples mas como cada desenvolvedor tem um hábito (um jeito) na qual de familiariza mais acabo ficando perdido nesse meio, infelizmente. Gostaria muito de desenvolver o MVC em uma forma que qualquer desenvolvedor que vier a ler o código entenda sem muitas dificuldades. Meu problema que realmente está me “travando” é o MVC. Mas vou tentar formular minha pergunta de uma forma abstrata que fique fácil as pessoas entenderem e poderem colaborar!

Muito obrigado mesmo por não ter se esquecido do tópico, fico muito contente!
[color=red]Um abração Bruno, felicidades.[/color]

É uma pessima pratica usar exceções para tudo… vc pode usar exceções para mensagens de negocio tranquilamente até é mais facil de manipular a app assim… pode ser feito o seguinte: criar somente 1 classe de excecao de negocio onde vc passe a menssagem tipo: cpf invalido, cnpj invalido, qualquer coisa invalida, dai caso for sua exceção de negocio ele a mostra na sua view como uma mensagem normal, e caso for um erro como um Nullpointer, ou uma exceção de banco de dados ele vai para uma pagina de erro… assim é bem mais facil de controlar isto…

Eu vou pela receita que a minha vó me ensinou: Nem oito nem oitenta.

É ruim ter quase nada, também é ruim ter em excesso. O ideal é o caminho do meio, saber medir.

Digo o mesmo para o próprio MVC, ele não é a solução para todos os problemas. Muita coisa é melhor resolvida sem ele, então não tente aprender tudo só trilhando esse caminho. É até bom que esteja travado, tente seguir por outros métodos de fazer a mesma coisa, uma visão diferente pode até te ajudar a entender melhor o que você estava vendo. Basta tempo e paciência.

Olá pessoal, boa noite!

Luistiagos, obrigado pela dica da Exception. Também pensei exatamente isso que falou!
Achei legal sobre os exception’s em geral. Como o controle seleciona a visão, caso uma exceção que não conheço ocorra, ele pode solicitar uma nova visão acusando um erro. Muito legal! :idea:
Porém quanto ao uso de uma Exception para tudo força que as informações de erro (menssagens) fiquem fora da visão e aparentemente seria melhor deixar detalhes da visão na visão, ou não?

Acho que o Laturner tem razão quando diz que estou muito “mente fechada” só para MVC. Mas estou estudando o caso do MVP também que o fantomas indicou em um post anterior e até mesmo o uso de frameworks postados bem anteriormente… até porque a teoria do MVC não diz nada sobre validações, banco de dados, exceções… Acredito que essa parte é livre para cada um implementar da forma que achar melhor como no nosso caso real de utilizar exceções para validações.

Assim sendo, tenho uma pergunta bem amadora: Quais as responsabilidades do controle no MVC para Desktop [color=red](não WEB)[/color]? O que ele de fato deverá fazer? :shock:

• Sabemos que a visão é quem mostra o estado do modelo ao usuário. (ou várias visões)
• Sabemos que é no modelo que estão os dados a serem exibidos.
• E o controle??? Essa foi uma pergunta feita no início do tópico que gerou muita discussão. :? Mas com o andar da carroagem a essa altura gostaria de saber de vocês o que entendem nesse momento que é dever do controle?

Opine, não deixe de opinar, seja veterano no tópico ou um novo leitor! Tem dúvidas, pergunte aqui também, sem se acanhar!
[color=orange][size=16]Obrigado a todos, sem exceções![/size][/color] (kkkk… :thumbup: )

Nem uma ídéia? :idea:
A pergunta está mal formulada? :?

Não respondi pq nunca trabalhei com Desktop. Umas perguntas retóricas:

Que diferença você vê entre Desktop e Web? Qual a diferença da View Web da View Desktop? Qual a diferença do Controller Web do Controller Desktop? Há diferenças entre Model Web e Model Desktop?

Também sou um aluno aqui

Boa tarde Bruno!
Vou responder aquilo que sei, pois WEB sou muito ruim. Mas vamos lá:

Desktop não precisa usar servlet’s como controlador. Porém para mim no Desktop o controlador só é uma “ponte” para visão e modelo se comunicarem.
Não faz validações, não trata eventos da visão… Não faz nada a não ser criar uma instancia do modelo para poder alterá-lo ou passar dados da visão para ele. E dependendo do que for solicitado na visão, pode trocar a visão ou alterar a visão sem fazer nada no modelo.

Desktop usa Swing/AWT.

Não existe, a não ser usar servlet.

Não existe, ao meu ver, é o mesmo.

Valew Bruno!

Uma situação:

Você tem uma aplicação desktop, e você move o model para um servidor remoto, numa máquina diferente. Não querendo que a cara da aplicação mude, você mantém a mesma view. Neste caso tem que mudar somente o Controller, considerando que eles mantém a mesma interface e tratamento de eventos da view?

Bruno, olá!

Bruno Laturner:

Uma situação:

Você tem uma aplicação desktop, e você move o model para um servidor remoto, numa máquina diferente. Não querendo que a cara da aplicação mude, você mantém a mesma view. Neste caso tem que mudar somente o Controller, considerando que eles mantém a mesma interface e tratamento de eventos da view?

:arrow: Então Bruno até aí entendi a situação! Só uma coisa que fiquei na dúvida: A visão deve ter uma interface e o controle um implements dessa interface da visão?

Na verdade, a pergunta é a seguinte:

A visão conhece o modelo para se reenderizar;
O modelo é o domínio do sistema. Não conhece ninguém.
O controle recebe eventos da visão e altera o modelo. É aí que surge a dúvida: Quando diz: “O controle recebe eventos da visão” significa que quando eu clicar em um botão da visão ela chamará um método do controle?

Ex:

Botão adicionar da visão chama controle.adicionar(par1, par2, par3);

Botão remover da visão chama controle.remover();

Aguardo pela resposta!
Quero deixar um abraço para o Bruno que tem me ajudado bastante aqui no fórum!

pedromuyala:

Na verdade, a pergunta é a seguinte:

A visão conhece o modelo para se reenderizar;
O modelo é o domínio do sistema. Não conhece ninguém.
O controle recebe eventos da visão e altera o modelo. É aí que surge a dúvida: Quando diz: “O controle recebe eventos da visão” significa que quando eu clicar em um botão da visão ela chamará um método do controle?

Ex:

Botão adicionar da visão chama controle.adicionar(par1, par2, par3);

Botão remover da visão chama controle.remover();

Aguardo pela resposta!
Quero deixar um abraço para o Bruno que tem me ajudado bastante aqui no fórum!

Oi Pedro,

Deixa eu intrometer um pouco… hehe…

Na verdade é o contrário, pelo menos como eu entendo - me corrigam se estiver errado - , é responsabilidade do controle avisar a visão quando alguma coisa mudar

Para entender melhor dê uma lida no pattern observer que vai te esclarecer bem

t+

Olá André, obrigdo por estar atento ao tópico!

Então o Observer avisa as visões sobre a mudança do modelo para que elas sejam reenderizada.
Até aí 100%. Porém, o controle recebe os eventos emitidos pela visão. Aí que eu quero entender que eventos são esses?
Ou seja, essa ligação dos eventos da visão com o controle é feita assim:

import javax.swing.*;
   import java.awt.event.*;

    public class View extends JPanel {
    
      private ClienteControl controller = null;
      private JButton btnExecute;
      private JTextField nome;   
      private JTextField cpf;   
      private JLabel lblCad; 
   
       public View(ClienteControl controller) {
         this.controller = controller;
         this.initialize();
      }
   
       private void initialize() {
         nome = new JTextField(10);   
         add(nome);   
         cpf = new JTextField(10);   
         add(cpf);   
         btnExecute = new JButton("Cadastrar");   
         btnExecute.addActionListener(
                new ActionListener() {
                   public void actionPerformed(ActionEvent e) {		     
                     View.this.cadastrar();
                  }
               });
         add(btnExecute);   
         lblCad = new JLabel();   
         add(lblCad);   
      }
   
       private void cadastrar() {
         try {
            this.controller.cadastrar(nome.getText(), cpf.getText());
            lblCad.setText("Cadastro realizado com sucesso");
         }
             catch (CadastroDeClienteException e) {
               lblCad.setText(e.getMessage());
            } 
      }  
   }