[quote=pedromuyala]Legal a postagem o conceito está certinho, é esse mesmo.
Quanto aos beans estarem soltos para todas as camadas tenho dúvidas no quesito manutenção. Imagine se for alterado um desses beans o estrago estaria feito!
Mas mesmo assim eu gostei da idéia parece estar bem fácil de entender… gostaria que falasse mais sobre ela: Como a visão irá lançar os eventos ao controle? O Observer vai, via source do evento, levar o bean até a visão ou ele será agregado a ela? Quem vai trocar a visão, por exemplo, após digitar alguns valores e esse ser validado pela lógica de negócio mudar a tela avisando o usuário que os dados foram digitados com sucesso?
[/quote]
Se você precisa que mais de uma visão saiba da alteração de um objeto, talvez você deva usar o padrão publish-subscribe, notificando as telas e mandando elas se atualizarem com o valor.
A visão não precisa “lançar” os eventos, ela pode identificar qual é a requisição e chamar um metodo apropriado no controle. Se for o caso, um objeto será retornado.
Na visão:
Usuario user = new Usuario( .. ); //Instancia o objeto passando os dados recebidos pelo evento
controle.cadastrarUsuario( user );
user = controle.obterUsuario( txtId.getText() );
txtNome.setText(user.getNome());
A troca de visão pode depender do seu contexto. Acho que haverá casos que tanto faz a visão chamar a próxima visão ou o controle fazer a troca. Até porque, existe programação errada, mas não existe “A” programação certa. Se funciona, está de acordo com os requisitos, e você não está quebrando padrões ou convenções, está certo.
Olá Felagund e Marcio, obrigado por participarem/acompanharem o tópico!
Estou respondendo com menor agilidade seguindo recomendações via MP dos companheiros para não dar impressão de estar forçando a resposta!
Então gostei muito, muito mesmo de todas as colaborações de todos os companheiros gujeiros que estiveram conosco participando, somente lendo ou criticando.
A atenção que cada companheiro disponibilizou do seu tempo aqui é um carinho que vale muito mais que qualquer coisa que podemos imaginar.
Mas preciso dizer uma coisa que andou ocorrendo aqui no fórum em diversos tópicos sobre MVC: Parece que existe uma (com desculpa da palavra) eterna confusão entre MVC e Camadas (tanto Tier quanto Layer) para alguns companheiros. Preciso assumir a todos que eu mesmo acreditava no MVC sendo uma arquitetura ideal para construção de um sistema independentemente do que seria desenvolvido mesmo lendo artigos de pessoas conceituadas com vaga experiência profissional.
Mas a essa altura e lendo as respostas nos diversos links relacionados na primeira postagem desse tópico ficou bem claro que não é bem esse o objetivo do MVC. Na verdade aprendi que um sistema deve ser desenvolvido em Layer’s (para não dizer camadas e novamente tornar ambíguo com camadas físicas) e o MVC pode estar presente em uma Layer (Ex: MVC na Apresentação) ou em várias Layer’s individualmente (Ex: 1 MVC na Apresentação e 1 MVC no Cliente) ou seja MVC’s independentes. Não existe UM MVC para duas, três, n Layer’s. O que existe é uma Layer onde pode ser aplicado o MVC mas não um MVC formado por várias Layer’s, agora estou certo? :roll:
[size=16]Portanto se isso que acabei de escrever tiver procedência real gostaria que fosse discutido então como funciona o MVC dentro de uma Layer.[/size]
Espero que agora sim as coisas comecem a fazer sentido na minha mente e pare de causar esse enorme desconforto entre os companheiros.
Preciso frizar uma coisa que já disse em tópicos anteriores: Eu estou aqui é para aprender, eu gosto dessa comunidade, gosto das pessoas que aqui participam e não tenho interesse nenhum por trás de tantas perguntas. O único interesse que tenho é igual a esse aí que acabei de escrever: Ajudar as pessoas, assim como a mim mesmo, a acabar com esses tipos de dúvidas que levam nossos amigos a eternas síndromes de confusão. E outra coisa que preciso frizar é para aqueles que acham que eu só quero audiência ao meu tópico. :x Eu prefiro que meu tópico tenha 1000 respostas e 1000 visitas do que ter 50 mil visitas e nenhuma resposta.
[color=blue]Só posso desejar felicidades a todos e muita saúde.
Espero pelas respostas, um abraço![/color]
Vamos lá então, deixa eu tentar colocar a minha opinião
[quote]At first glance, the three tiers may seem similar to the MVC (Model View Controller) concept; however, topologically they are different. A fundamental rule in a three-tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middleware tier. Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model.
[/quote]
Ou seja, a separação física das camadas (tiers) diz que elas se comunicam linearmente. No exemplo de uma aplicação web você poderia dizer que o browser do cliente é uma camada, o application server onde fica a lógica de negócio é outra camada e o banco de dados é outra camada…
Essas seriam as camadas físicas do seu sistema
Já com relação a separação em camadas lógicas você poderia considerar que teriamos a tal separação de responsabilidades. O seu view irá enviar os inputs de dados para o seu controller, que irá atualizar o seu banco de dados e o seu view irá consultar (ou será avisado) pelo controller quando alguma alteração ocorrer
A grosso modo separar em camadas físicas significa que eu posso ir lá e arrancar pedaço do código, ou por exemplo, se o seu banco de dados cair uma camada vai junto.
Já separar logicamente significa que cada camada tem uma responsabilidade bem definida, e no caso de ela não ser mais suficiente você pode simplesmente substituir este pedaço da sua aplicação por outro pedaço que tem a mesma responsabilidade.
Se tiver tempo dê uma lida também nos artigos abaixo
Olá André, puxa obrigadão por continuar participando!
Entendi direitinho cara a explicação. E acredito que a sua intensão foi me dizer, a princípio, para que eu estude Camadas, não é?
Até porque do jeito que você descreveu as camadas lógicas é exatamente o que eu preciso! Uma visão que envia dados ao seu controlador e realiza a persistência em banco de dados. Após isso a visão é avisada para se atualizar (e o Observer eu aprendi também em um link que você indicou :D) Se em um modelo de camadas lógicas essas responsabilidades ficam definidas, é o que eu realmente procuro. E também entendi as camadas físicas, muito legal!
Poxa você sempre que pode me “destrava” em problemas enrolados. Acho que tem competência o suficiente para ser um moderador do GUJ, espero que leiam isso! :-o
Obrigado mais uma vez, fico no aguardo pela resposta!
[quote]
Portanto se isso que acabei de escrever tiver procedência real gostaria que fosse discutido então como funciona o MVC dentro de uma Layer.[/quote]
Todo o sistema que trabalha com informação ( e aqui se incluem até sistemas fisicos e quimicos) precisa de input e output.
Isto é essencial e obvio. Cada andar (layer) precisa destas coisas. Mas cada andar está empilhado em outros andares.
Isso significa que existe um input vindo de cima, um output indo para baixo e de volta.
cima ---> andar ---- > baixo
<---- <-----
OO diz que objetos devem ter responsabilidade unicas e separadas então a primeira coisa a fazer é criar dois objetos
um para a comunicação “acima” e outro para a comunicaão abaixo
cima <—> [ A … B] <—> baixo
“A” será responsável por tratar o input de cima. Traduzi-lo para algo enterpretável pelo andar , isso será tratado e passado a B que traduzirá para o andar de baixo. B traduzirá a resposta de volta e A de volta ao andar de cima. Hum… será trtado por quem ?
PRecisamos deum terceiro objeto C, que fará o tratamento.
cima <—> [ A <–> C <–> B] <—> baixo
Esta é o design padrão de um andar. Agora imaginemos que este andar responde directamente ao usuário ou os comandos do usuário : teclas, mouse, etc… “A” estará disposto a responder a coisas como “usuario clicou em X” Este é o input que A recebe.
Mas não existe hora marcada para isso. Então entra o conceito de Evento. Algo acontece. Quando acontece isso desencadeia as chamadas aos andares de baixo. “A” é “activado” por um evento. Mas o evento é algo assincrono. Outro evento pode imediatamente seguir-se a esse. Um deslocar de mouse geram N eventos em pouco tempo. Então A não pode esperar pela resposta de C porque já precisa ficar disponivel para enviar outro evento. Esta cadeia de eventos força um processo assincrono em que a resposta não chega imediatamente. Mas quando ela chegar , A tem que ser informado. E quem sabe quando ela chega? O cada da outra ponta, B. Então a mecanica de eventos força uma separação
A ---> C --> B --
|
^ |
|---------------
É um triangulo. A invoca C que invoca B que invoca A mas nunca a informação volta para quem chamou.
É deste triangulo que nasce o MVC.
M = modelo, é o nome de B. V = View é o nome de A e C = controler é o nome de C.
A view recebe o input e fornece o output ao andar superior. Model fornece o input e recebe o output do andar inferior. C controla o fluxo. Ele pode não chamar B e simplesmente enviar um evento a A, em nome de B.
Isto é o padrão. A implementação são outros 500.
Dependendo do propósito a implementação pode ser complexa ou não.
Não ha receita de como seria a implementação. O ponto é que se for no padrão MVC ela respeita certas regras de separação de responsabilidade. Mas lembre-se que MVC presupoe o uso de eventos. Deveria ser o padrão MVCE. Mas o que é um evento na relalidade ? como se implementa um ?
Em java isso é transparente. É a chamada a um método. Só que assim, não ha diferença entre um método-evento e um método normal. Pois. E por isso que é tão util e interessante, e simples em java trabalhar com eventos. Em outras linguagens um construto diferente de “método” é necessário para representar o evento.
É preciso tb deixar claro que MVC podem ser 3 objetos ou 1000 objetos. O M , o V e o C podem utilizar quandos objetos de tipos diferentes forem necessários. Normalmente uma implementação MVC é componentizada e cada componente assume um dos papeis do MVC. Como disse, a implementação pode ser simples ou complexa.
Olá pessoal, é o Pedro, [color=red]estou de volta[/color]! Depois de passar por alguns sérios problemas acredito estar são e salvo! 8)
Muito bom estar devolta com todos, é muito bom estar aqui!
Infelizmente não vou poder, até este momento, conectar na Internet no meu horário de serviço que agora está proibído. :roll: (troquei de emprego )
Hoje vou atender um pedido de alguém que me procurou via mensagem privada. Prometi ilustrar a explicação do Sergio Taborda acima para que fique bem visível a quem esteja com dificuldade para enxergar algumas arquiteturas de software. Óbvio quero deixar bem claro aqui que estou confiando na explicação do Taborda. Não estou de forma alguma julgando estar correta ou errada…
Muito menos se entendi certo ou errado, caso percebam que estou cometendo um delito aos programadores, por favor, não deixem de postar a opinião aí embaixo, pelo amor de Deus! :shock: kkkkk…
Isso ilustra bem o que foi dito na mensagem anterior. SE ESTIVER ALGO QUE JULGUEM INVÁLIDO, ERRONEO, RIDÍCULO… por favor comentem aí abaixo! :idea:
:arrow: Estou anexando a imagem também para quem quiser ver em alta resolução, ok?
[size=16]E é isso amigos companheiros Gujeiros![/size]
[color=orange]Espero dessa vez manter uma estabilidade aqui com vocês![/color] Um forte abraço para todos, estamos juntos!
Olá Pedro, obrigada por estar se preocupando em me ajudar!
Deixa eu fazer uma obs rápida: Atualiza sua primeira postagem no tópico que a última atualização que fez foi em 2009 hihihihihi…
Então, infelizmente eu tentei ler todo o tópico mas como é muito grande e lá mais para o meio chega a ser “confuso”, me limitei em ler apenas as 4 últimas páginas…
Mas acredito que fiz certo pois a dúvida está alí mesmo nas últimas postagens. E é Desktop como está no título porque de JAVA WEB eu nem conheço!
Vamos ver se captei a ídeia, mesmo já sabendo disso (estudei sobre arquitetura em alguns sites da Internet): O que você quer passar é que Camadas e MVC são duas coisas parecidas, porém distintas, conforme mostrou na imagem que criou para mim (q lindo, muito obrigada, adorei!!!), certo? Que dentro de um andar existe uma arquitetura MVC mas que não existe dentro de um MVC vários andares, certo?
Olhando a explicação anterior (do Sergio) a imagem está representando 100% o que foi dito.
Então o que me confunde é exatamente isso: Sabemos bem que arquitetura é abstrata. No meu caso eu quero criar uma Agenda para guardar os dados das pessoas que conheço para futuramente me comunicar com elas. Para que eu siga esse desenho de arquitetura mostrado na imagem, como teria que dividir minhas classes para que fique de acordo?
Apresentação: Seriam as telas exibidas ao usuário? (De cadastro, de confirmação de cadastro, de alteração, de consulta,…)???
Negócios: Seriam as regras de negócios e validações? (Não pode cadastrar pessoa duplicada, obrigatório informar um ou mais telefones, e-mail deve conter “@”,…)???
Dados: Seria o Crud para persistir em bando de dados?
Outra coisa você usa MVC na camada de negócios (que está com o sinal de “-”). As outras que estão com o sinal de “+” contém a mesma hierarquia?
Obrigada por atender meu pedido via MP, muito legal sua atenção em se preoucpar em ajudar!
Parabéns pelo Português você também tenta escrever bem legível… fica mais fácil entender. :oops:
Magina moça não precisa agradecer! Espero poder ajudar, só isso.
Pedido atendido, está atualizado.
Então é isso mesmo, se nós, claro, não estivermos errados. MVC, conforme desenhei, está presente internamente na camada. Uma camada de nome CAM tem um input (visão), um output (modelo) e um centro de processamento (controle). Tendo isso em mente, lá vai:
CAM recebe dados de uma camada superior através do seu input que nada mais é que a visão (podendo ser humana ou não);
Visão, então, pela convenção de eventos, lança um evento ao controle;
Controle que está escutando a visão recebe o evento e o processa de forma legível para a aplicação;
Controle, neste momento pode tomar duas decisões: fazer alteração no modelo ou responder diretamente a visão;
— Então, uma breve pausa no processamento acima para lembrar um detalhe importante: Na convenção de eventos em que um evento pode acontecer a “qualquer instante” o controlador precisa estar sempre livre para receber novos eventos e processa-los, sendo que não pode ficar aguardando uma resposta do modelo o qual, atráves de eventos também, se comunica-rá diretamente com a visão para reenderiza-la. (Caso tenha dúvidas sobre eventos, estudar o pattern Observer) Continuando…
Se controle optar em responder diretamente a visão, ela receberá a resposta e exibirá ela (pode ser para um humano ou não);
Se controle optar em alterar o modelo, então passará os dados a ele;
O modelo poderá enviar dados a uma camada inferior e receber dados dela;
Se o modelo for alterado, a visão será notificada.
Pronto… Ufa! Acho que consegui explicar!
[quote=ingridfarabulini]Então o que me confunde é exatamente isso: Sabemos bem que arquitetura é abstrata. No meu caso eu quero criar uma Agenda para guardar os dados das pessoas que conheço para futuramente me comunicar com elas. Para que eu siga esse desenho de arquitetura mostrado na imagem, como teria que dividir minhas classes para que fique de acordo?
Apresentação: Seriam as telas exibidas ao usuário? (De cadastro, de confirmação de cadastro, de alteração, de consulta,…)???
Negócios: Seriam as regras de negócios e validações? (Não pode cadastrar pessoa duplicada, obrigatório informar um ou mais telefones, e-mail deve conter “@”,…)???
Dados: Seria o Crud para persistir em bando de dados?
[/quote]
Cada camada vai ter o M-V-C. No caso da imagem acima, o MVC está presente de forma visual na Camada de Negócios. Mas ele poderia estar em qualquer uma delas, nas três ou em nenhuma.
Suas classe devem ser criadas de acordo a camada. No caso de uma agenda, como cita de exemplo, a camada de apresentação teria como visão um formulário, um controle que receberá eventos do botão quando clicado e traduzirá ao modelo ou a própria visão e um modelo que executará as regras para aquele formulário. Se tudo estiver satisfeito, o modelo (domínio) da apresentação enviará os dados a visão da camada de negócios que acionará um evento ao controle que então chamará o modelo para verificar as regras de negócio que dessa vez são da agenda (não mais do formulário, como na camada de apresentação). Então, por fim o modelo enviará para a visão da camada de dados os dados necessários que lançará um evento para o controle que chamará o modelo e após tudo ok a informação é então persistida em BD e as respostas aos eventos lançados começam a ser devolvidas até chegarem novamente lá na camada superior. Pronto… Ufa 2!
Sim. como disse isso depende de como você quer implementar, não é obrigatório. Você poderia ter o MVC na camada de apresentação, somente.
Bem tudo respondido agora preciso fazer um [color=red][size=24]ALERTA!!![/size][/color] [size=18]Eu acredito que seja isso, com tudo que venho estudando e tentando entender, não estou afirmando nada que seja isso!!![/size] Posso aqui estar fazendo uma baita asneira daquelas se envergonhar até a sogra :oops: :oops: :oops:!!! Mas isso só saberemos mesmo nas próximas postagens dos companheiros Gujeiros que com certeza em breve começaram logo abaixo. E eu peço que por favor opinem mesmo porque se isso for um erro, no lugar de estar ajudando milhares de visitantes estarei é causando um desastre a eles!
[size=14][color=orange]Obrigadão a todos que continuam firmes e fortes conosco nesse mundo maravilhoso do JAVA!
Abração a todos, felicidades![/color][/size]
Só um adendo… o ideal é que o controle não tome decisões,
o ideal é o controle conhecer o fluxo, saber para onde enviar cada evento do sistema, mas não tomcar decisões…
O limiar desse conceito é bem dificil, pq é complicado ate de explicar o que seria tomar decisão ou não, afinal escolher o fluxo correto é um decisão…
…
Mas o que falo é que além de ifs, cases, e enums, sempre que possivel, o Controle deve delegar ao dominio a tomada de decisão, e com a decisão tomada o controle cuida de enviar o fluxo…
por exemplo
se vc quer checar se os dados estão corretos, parar só ai mandar o fluxo para o cadastro, vc não deve fazer o teste no controle, e sim delegar esse teste ao dominio, a lógica mesmo…
Nossaaa! Eu estou entendendo tudo mas preciso me aprofundar nessa teoria estou entendendo mas muito superficialmente. :roll:
Vou digerir tudo isso tentando implementar a agenda e volto para postar se surgirem dúvidas…
Obrigada Pedro e Lavieri, você estão me ajudando muitooooo
[quote=ingridfarabulini]Nossaaa! Eu estou entendendo tudo mas preciso me aprofundar nessa teoria estou entendendo mas muito superficialmente. :roll:
Vou digerir tudo isso tentando implementar a agenda e volto para postar se surgirem dúvidas…
Obrigada Pedro e Lavieri, você estão me ajudando muitooooo [/quote]´
Olá,
Estive dando uma olhada no seu tópico anterior e, agora, neste… o que tenho a sugerir é que siga o que foi proposto pelo lavieri pensar na divisão de tarefas vai promover a alta coesão e, com os objetos conhecendo o mínimo possível sobre os demais você consegue atingir o baixo acoplamento… Assim, você conseguirá fazer com que seu sistema tenha maior qualidade no sentido da orientação a objetos.
No entanto, pelo que pude ver em suas mensagens… essa explicação toda pode ter te deixado meio confusa… tenho um link de um material que considero muito interessante e que pode ajudar a visualizar melhor a situação proposta pelos colegas do fórum:
Olá Eberson…
Então pensando exatamente dessa forma que considerei a teoria do Sergio Taborda e a imagem representando ela feita pelo Pedro. Não que o Lavieri esteja sem razão, não não…
Se você notar, poderá perceber que na explicação existe uma alta coesão e um baixo acoplamento. Foca somente um andar lá… vai perceber que na verdade esse andar é um MVC com entrada, processamento e saída [IN-<>process<->OUT]. E porque do MVC dentro desse andar? Justamente para o baixo acoplamento acontecer entre as partes, que é justamente a convenção de eventos criada (note que onde há setas com tracinhos na imagem “---->” lê-se “lança um evento”.
Acredito que a teoria está correta… masssss… quem realmente poderia dizer se é certo ou não a imagem que estamos vendo seria o próprio Sérgio Taborda quem descreveu a teoria… vou ver se entro em contato com ele!
O que eu busco é bem isso aí acima mesmo. A sugestão dada pelo Lavieri no outro tópico é muito legal mas se essa agenda começar a aumentar? Tiver que colocar mais coisas como fotos, enviar um e-mail?? O agendinha passa a ser um agendão! Acredito que devo desde o início acreditar que essas coisas possam ocorrer… por isso quero fazer uma base legal antes de continuar… :shock: Nossa hoje falei demais!
Antes demais queria agradecer o esforço de ter criado esse boneco. A minha unica sugestão é que o miolo mvc deveria aparecer na camada de apresentação porque é onde ele realmente é usado a esmagadora maioria das vezes. Um conceito pictorico é representar MVC como um triangulo para que não reste duvida de que não ha uma unica seqüência de eventos.
Realmente como foi dito o controlador não toma decisões de negocio. Isso é o model que faz ( por isso que ele tem comunicação com a camada abaixo).
O boneco da direita não entendi. Não ha relação entre MVC e os andares. O que foi representado com aquelas “salas” são andares, não camadas, nem mvc. ficou algo confuso objetivo dessa parte da imagem.
CRUD não é Dados, é Integração. são 5 camadas : Cliente, Apresentação, Negócios, Integração , Recursos (dados)
O MVC é para ser usado no Cliente e opcionalmente na Apresentação (em web se usa nos dois)
Mas no geral é isso mesmo. Parabéns por ter entendido.
P.S. Só para deixar claro
Cliente = telas , aspecto visual,ergonomia
Apresentação = apoio ao Cliente. Traduz o interno para o externo e de volta.
Negocio = as regras da aplicação (tb chamado Dominio)
integeração = onde estão os dados e como colocá-los fisicamente lá e depois recurperá-los (hibernate, jdbc , essas coisas) + As regras de persistencia (duplicados, indices, etc). Tb se inclui leitura de arquivos de propriedades, xml ou outros que aplicação necessite
Recursos = os dados em si. Arquivos, imagens, e o proprio SGDB.
[quote=ingridfarabulini]
O que eu busco é bem isso aí acima mesmo. A sugestão dada pelo Lavieri no outro tópico é muito legal mas se essa agenda começar a aumentar? Tiver que colocar mais coisas como fotos, enviar um e-mail?? O agendinha passa a ser um agendão! Acredito que devo desde o início acreditar que essas coisas possam ocorrer… por isso quero fazer uma base legal antes de continuar… :shock: Nossa hoje falei demais!
Obrigada Eberson :D[/quote]
não me entenda mau ^^, minha sugestão é exatamente para vc pensar em um modelo como o exposto nesse topico… eu apenas exemplifiquei pequenos trechos de codigo, para que vc entendesse um pouco também do código do problema também.
pensar em sistema pequeno é falho, e o sergio enclusive tem um artigo falando justamente disso.
Olá [color=blue]Sergio Taborda[/color], muitíssimo obrigado por continuar atento ao tópico mesmo depois de um bom tempo parado. Para mim, particularmente, é uma honra saber que está presente.
Não precisa agradecer absolutamente nada, se alguém tem que agradecer aqui sou eu pela sua presença.
[color=red]Fiquei curioso: Em um sistema Desktop, existe tanto a Camada de Cliente quanto a de Apresentação, ou seja, as duas?[/color]
Concordo quando fala em triângulo a arquitetura MVC. O boneco a direita-inferior representa isso.
É também dou razão a você e ao Lavieri também que logo de cara alertou esse problema. Infelizmente aí eu comi bola, bati na teoria. OBRIGADO POR AVISAREM!!! MUITO BOM.
[color=red]Não pode ser usado em nenhuma das outras 3 camadas? (Negócios, Integração e Recursos) Existem outras arquiteturas para tal?[/color]
[color=red]Fiquei confuso… Como ficaria/seria, por exemplo, o sistema da agenda que a Ingrid quer criar usando essas camadas no JAVA SWING?[/color]
Lembrando claro que o próprio Sergio já fez uma explicação sobre MVC + Swing em um tópico anterior. Mas eu não consigo visualizar, como por exemplo, esse caso da agenda?
[size=14]Olha mais uma vez tenho que agradecer muito a boa vontade de todos que continuam aqui firmes acompanhando este tópico
Volto a dizer que o GUJ proporciona um espaço mágico para as pessoas com excelentes profissionais atuando nas mais diversas áreas da computação.
Isso é um exemplo para toda a sociedade… pessoas buscando ajudar as outras, as encaminhando no melhor caminho. O mundo inteiro deveria ser assim… infelizmente não é.
Mas são esses detalhes que fazem um mundo melhor!!! Um dia todos nós chegaremos lá.[/size]
[size=16]Parabéns mais uma vez aos organizadores do GUJ e a todos os seus usuários que colaboram respondendo perguntas ou simplesmente dispondo do seu tempo para acompanhar o tópico. Fico no aguardo pelas respostas, felicidades a todos.[/size]
Primeiro , tenha cuidado com o uso de cores. Vc meio que está violando a netiqueta. Para duvidas procure um moderador.
Pode, claro que pode. Mas normalmente não faz sentido nessas camadas. Lembre-se que o MVC existe para responder a eventos. Normalmente essas camadas não são guiadas por eventos. Mas teoricamente nada impede o seu uso. Apenas não é comum usar nessas camadas pq normalmente não encaixa.
Nenhuma das camadas é obrigatória, contudo é bom ter todas.
No caso do swing o cliente é o que vc monta com o swing. Vc engendra uma estrutura que media com o usuário, isso é o cliente.
Mas ai vc precisa que os seus models do swing conversem com o resto da aplicação. Essa tradução é feita na camada de apresentação.
É mais dificil ver a destinção e é mais ainda se não houver uma correta separação de responsabilidades entre as classes.
Estava olhando bem para o desenho na postagem lá no alto e lí os posts seguintes e não entendi um detalhe: vamos dizer que o mvc esteja implementado no andar superior, e essa camada seja Cliente. Se eu clicar em um JButton na verdade quem está se comunicando com a camada de apresentação é o controle e não o modelo do JButton, não é ? O actionListener vai chamar um método do andar inferior… mas não o model quem irá chamar.
Mais um detalhe: essas setas pretas de duplo sentido (vai-e-vem) nomeadas IN/OUT seria uma comunicação por eventos? Pergunto porque se se estiver duas telas abertas que representem o mesmo domínio e uma delas altrar algo, ambas devem imediatamente refletir seu modelo… senão isso não aconteceria, acho. :?
JButton segue um padrao observer para comunicar o evento, entao ele em si, nao e’ acoplado a quem estiver o escutando…
e’ igual um radio… o cara transmite a onda de radio, quem esta escutando ou nao, nao e’ responsabilidade da estacao de radio, ela so envia o sinal… a pessoa que quer ouvir que tem q sintonizar na radio para escutar … nao existe acoplamento entre entre a Estacao de Radio e quem a escuta…
Observer e’ um padrao na mesma linha… o controle que sintoniza para escutar os eventos do botao… portanto… o controle que tem q saber o botao que ele quer ouvir, se colocar como ouvinto do botao, adicionando ao botao um ActionListener
…
Assim o botao nao se importa de quem o escuta… toda vez que ele precisa informar o evento, ele simplismente vai gerar um evento, e quem estiver sintonizado em sua estacao, ou seja, em sua lista de listeners, vai escutar esse evento…
[code]public class Mensageiro {
public Mensageiro(Receptor receptor) { //forte acoplamento
this.receptor = receptor;
}
public void fazAlgo() {
receptor.aviso("eu fiz algo"); //forte acoplamento, eu conheco quem estou enviado a msg
}
}[/code]
Agora com baixo acoplamento, usando observer
[code]public class Mensageiro {
private Set receptores = new HashSet();
public Mensageiro() {}
public void addObserver(Receptor receptor) { receptores.add(receptor);}
public void removeObserver(Receptor receptor) { receptores.remove(receptor);}
private void avisa(String msg) {
for(Receptor receptor : receptores) receptor.aviso(msg);
}
public void fazAlgo() {
avisa("eu fiz algo"); //BAIXO ACOPLAMENTO
//aqui vc esta avisando... mas nao faz a menor ideia de a quem...
//simplismente qualquer um sintonizado na sua estacao, ou seja,
//adicionando a lista de repectores, vai receber o aviso
}
}[/code]
public interface Recptor {
void aviso(String aviso);
}
Olá Sergio, obrigado por responder as perguntas e continuar atento ao tópico, fico muito feliz!
Com certeza vou seguir sua recomendação… realmente fui infeliz em querer destacar as perguntas de vermelho. Fico triste pelo erro.
Mas foi bom ter chamado a atenção, até lí sobre “netiqueta” no Wikipédia. Muito legal, não conhecia! Obrigado pela dica
Peço desculpas pelo transtorno… evitarei ao máximo! Gosto muito da comunidade, espero não prejudicar!
Não há dúvidas que o conceito está bem claro para mim. Que coisa, acho que agora estou conseguindo entender definitivamente seu raciocínio…
Mesmo assim, ainda preciso fazer três perguntinhas:
É normal o modelo ter uma coleção de Listener’s que possa registrar as visões que implementarão esse mesmo Listener e passarão a receber eventos de “notificação de alteração” do modelo?
É normal a visão ter uma coleção de Listener’s que possa registrar os controladores que implementarão esse mesmo Listener e passarão a receber os eventos de “user gestures (Ex: Click’s,etc…)” da visão?
Vários controladores podem escutar a visão assim como várias visões podem escutar o modelo (desde que se registrem como ouvintes)?
Obrigadão a todos que estão acompanhando! Espero pela resposta companheiros!
