[size=15][color=red]ATENÇÃO NOVO VISITANTE:[/color][/size] 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)
[size=14][color=blue]QUERO AGRADECER:[/color][/size] 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! (13/07/2009)
[size=14][color=blue]QUERO ME DESCULPAR:[/color] Pela minha ausência ao fórum durante quase três meses (de início de Novembro até inicio de Fevereiro). Infelizmente passei por alguns problemas pessoais aos quais, graças a Deus, estou são e salvo. Foram os piores meses que passei longe das principais coisas que mais gosto na vida, mas não vou ficar aqui lamentando aos companheiros! Bola para frente.[/size] (21/03/2010)
[size=13][color=green]OUTROS TÓPICOS AUXILIARES:[/color][/size] Companheiros para ajudar ainda mais os usuários da comunidade vou relacionando outros tópicos encontrados durante as minhas pesquisas aqui dentro do GUJ com o assunto sobre MVC que trazem mais conteúdo a quem está aprendendo sobre o assunto. Espero que esses também possam colaborar com todos! Obrigado. (27/10/2009)
OBS: Os tópicos antigos sobre MVC não serão mais “ressucitados” atendendo a um pedido da administração do fórum. (21/03/2010)
Muito simples: A visão pode alterar o modelo sem passar pelo controle, eu pergunto, direto? Ou o modelo para a visão é só reenderização :?:
Obrigado companheiros da programaçã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…
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!
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…
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 :?:
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.
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.
[quote=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…[/quote]
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:
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.
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.
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.
[/quote]
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:
[quote]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.
[/quote]
Entende-se então que o controle não vai, de forma alguma, dar set’s (atualizar algo) na visão. Concorda?
Modelo model = new Modelo();
Visao view = new Visao(model);
Controle control = new Controle(view, model);
Se é assim realmente, tenho algumas dúvidas. São elas:
1ª Validar) Quando o controle pegar os dados vindos da visão (jtextfields.getText()) e validar (tipos, tamanho, validarCPF, etc…) se 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:
(27/10/2009)
