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

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

ATENÇÃO NOVO VISITANTE: Se a sua intenção é ajudar respondendo perguntas e não ficar confuso entre tantas perguntas e respostas no tópico, recomendo que inicie sua leitura a partir da data de 23/10/2009 (que está dos 160 posts para frente, página 11). Porém se a sua intenção é aprender, recomendo uma leitura cuidadosa de todo o tópico e dos outros já postados anteriormente aqui no GUJ. O tópico está grande justamente para que eu não fique abrindo tópicos novos a cada pergunta relacionada ao MVC. Quem quiser aproveitar o embalo do tópico (já que este está sendo acompanhando por uma boa galera) e postar perguntas novas RELACIONADAS AO MVC, fiquem avontade. Felicidades a todos!

(27/10/2009)

QUERO AGRADECER: A todos que estão colaborando, mesmo com o tópico gigante estão acompanhando, mandando ajuda pelo MP (Mensagens Privadas, além que acho, na minha opinião, que as respostas devem ser postadas para todos) e os novos visitantes que também estão ajudando muito. Como disse desde o início sou um aprendiz em JAVA e se não fosse o GUJ para proporcionar essa rede maravilhosa com certeza para mim seria muito ruim aprender alguma coisa. Realmente não tenho palavras para agradecer. Muito Obrigado!

Obrigado companheiros da programação

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

JavaGuru Membro desde: 28/08/2008 20:38:07 Mensagens: 200 Offline

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

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

markin1 wrote:/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!!!

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

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.

JavaGuru Membro desde: 28/08/2008 20:38:07 Mensagens: 200 Offline

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,

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

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.

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

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

Ninguém mesmo? Nem uma idéia?

JavaGuru Membro desde: 28/08/2008 20:38:07 Mensagens: 200 Offline

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,

JavaEvangelist Membro desde: 02/01/2009 19:08:04 Mensagens: 340 Offline

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?

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

rodrigo.ferreira wrote: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...

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.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

rodrigo.ferreira wrote: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.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

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

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.

Notícias, artigos e o maior fórum brasileiro sobre Java