Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
Um problema que eu vejo tanto no MVP como no MVC é a passagem de dados entre o View e o Model. Vejam só: tenho uma tela por exemplo com 26 JTextFields e um JTable para efetuar uma pesquisa. Para mapear meu objeto eu preciso de 26 textFieldXXX.setText(meuObjeto.getAtributoXXX) e mais 26 para fazer o contrario, ou seja, popular meu objeto. Será que usando algum framework de binding eu estaria "ferindo" esse pattern? Qual a maneira, dentro de padroes, mais completa que voces acham que há?
Abração!!! _________________Eu vou te deletar, te excluir do meu Orkuuuuut. Eu vou te bloquear no Eme Esse EEEEEEne. Nao me mande mais scraps nem e-mail, Pooower Point. Me exclua também, e adicione ele!!!!
Poisé Carlos esse problema realmente existe. É muito set e get para pouca lógica. Mas não vejo como uma solução de bind como uma quebra de pattern, ela apenas está carregando tudo automaticamente. Basta que siga as "exigências" do pattern. Exemplo:
Carregar via reflection todos os componentes que possuem o mesmo nome que os atributos do modelo. (Solução interessante).
Acho realmente que MVP é o mais "correto" para ser utilizado pelo pessoal que desenvolve interfaces, pois foi feito para isso. Tratamento de eventos, lógica de apresentação e etc.
A solução do Vitor é bem interessante.. podemos até fazer algo parecido pra testar.
Mas não acho que a necessidade de criar os métodos acessadores seja um problema.. assim como as IDEs hoje dispõem de opções do tipo 'Encapsulate Fields', pra gerar os get() e set() da classe, podem existir plugins que criem esses 'ganchos' automaticamente para nós (essa feature no NetBeans ficaria saborosa!)... _________________Daniel F. Martins
A solução do Vitor é bem interessante.. podemos até fazer algo parecido pra testar.
Usa o JForms ( http://jforms.org ) . Não é bem assim, mas já da para ter uma idéia.
TriTonE
Mas não acho que a necessidade de criar os métodos acessadores seja um problema.. assim como as IDEs hoje dispõem de opções do tipo 'Encapsulate Fields', pra gerar os get() e set() da classe, podem existir plugins que criem esses 'ganchos' automaticamente para nós (essa feature no NetBeans ficaria saborosa!)...
Não é um problema, é chato! É muito código que não faz nada.
Sabe o que é mais foda? Tipo assim: Imagina só um front-end com três JTextField: nome, idade e telefone. Um bean com os mesmos campos, sendo que idade é Integer e os outros são String. Um framework podia usar reflexão para mapear da view para o model e vice-versa.. até aí beleza.
Mas imagine que você troque os JTextField por um outro controle qualquer, que não possui os métodos getText() e setText().. aí complica!
Ou então, imaginem outra situação.. Na sua view, você renderiza propriedades de diversos componentes de negócio ao mesmo tempo, como por exemplo, os dados de um Cliente, seus Pedidos, etc. E possivelmente dois ou mais desses componentes possuem propriedades com nomes idênticos.. Não ficaria muito complexo criar um mecanismo de mapeamento que seja capaz de lidar com uma situação dessas? _________________Daniel F. Martins
Mas imagine que você troque os JTextField por um outro controle qualquer, que não possui os métodos getText() e setText().. aí complica!
O Framework que usará a reflexão tem que tratar todos os componentes possíveis (Talvez criando Adapters para interfaces conhecidas).
TriTonE
Ou então, imaginem outra situação.. Na sua view, você renderiza propriedades de diversos componentes de negócio ao mesmo tempo, como por exemplo, os dados de um Cliente, seus Pedidos, etc. E possivelmente dois ou mais desses componentes possuem propriedades com nomes idênticos.. Não ficaria muito complexo criar um mecanismo de mapeamento que seja capaz de lidar com uma situação dessas?
Sim, tem que prever esse tipo de coisa. Talvez colocar a classe antes do atributo a configurar. Telas Master/Detail também são complexas . Se tiver uma Collection dentro do modelo, coloca no grid que está na tela.
Ai que ta, isso existe. O JGoodies Binding faz isso, ele tem funcoes "helpers" para fazer o bind entre sua classe e determinado tipo de widget. O interessante é que ele trata inclusive binds do estilo ligar um checkbox com um atributo na classe do tipo String que possa ter o valor "sim" ou "nao". Eu achei fantastico esse framework apesar de, devido a um bad design da minha parte, eu nao ter podido usa-lo em meu sistema com os 26 JTextFields que eu havia falado. A minha duvida realmente era se esse framework nao feria a minha pattern. Mas pelo que eu vejo nao, da para implementar todo esse framework na parte do Presenter, pois pensando bem ele é uma especie de Controller por ligar o View com o Model. Valeu ai pela discussao, pois deixou o negocio bem claro para mim. Ah, e vejam esse binding, vale a pena http://www.jgoodies.com[/url] _________________Eu vou te deletar, te excluir do meu Orkuuuuut. Eu vou te bloquear no Eme Esse EEEEEEne. Nao me mande mais scraps nem e-mail, Pooower Point. Me exclua também, e adicione ele!!!!
Se eu não me engano, o JGoodies utiliza componentes Swing customizados para conseguir fazer o binding, não é? Pois se a resposta for sim, então temos um sério problema, que seria o seguinte: seria praticamente impossível utilizar uma ferramenta como o Matisse para gerar as interfaces gráficas.
No mais, eu vou conferir melhor esse JGoodies, parece legal _________________Daniel F. Martins
No Matise vc pode colocar seus proprios componentes na paleta, não? Acho que não tem nada de tão monstruoso fazer isso não. Mas, vamos ser mais praticos e colocar algum codigo:
Esse componente, BindableTextField pode ser adicionado ao Matise, não (Oh Ronaaaaaald!)? Agora, na vc pode ou:
1. Criar uma nova interface para dizer que a Window, Frame, Dialog, etc sabe como tratar com os bindables dentro dela - isso pode ser feito com reflection/introspection de uma maneira relativamente automatizada;
2. Criar o mecanismo de bind a parte, e usa-lo nos event listeners.
Ei, eu fiz usando matisse!!!! funciona sim, é só la nas propriedades do teu textField, voce trocar o creation code para o codigo especifico do framework de binding!!
Abração!!! _________________Eu vou te deletar, te excluir do meu Orkuuuuut. Eu vou te bloquear no Eme Esse EEEEEEne. Nao me mande mais scraps nem e-mail, Pooower Point. Me exclua também, e adicione ele!!!!
Voce pode "plugar" seu widget com o binding depois de ele ter sido criado. Só que dessa maneira voce nao foge do codigo macarrônico que eu estava falando no principio. _________________Eu vou te deletar, te excluir do meu Orkuuuuut. Eu vou te bloquear no Eme Esse EEEEEEne. Nao me mande mais scraps nem e-mail, Pooower Point. Me exclua também, e adicione ele!!!!
Nao da pra excluir topicos? Eu queria escrever mais uma coisa. O Binding nao usa componentes especificos na verdade... Ele usa Adapters se voce quiser algo enxuto ou um esquema "plugavel" se voce quiser algo mais separado. _________________Eu vou te deletar, te excluir do meu Orkuuuuut. Eu vou te bloquear no Eme Esse EEEEEEne. Nao me mande mais scraps nem e-mail, Pooower Point. Me exclua também, e adicione ele!!!!
No Matise vc pode colocar seus proprios componentes na paleta, não? Acho que não tem nada de tão monstruoso fazer isso não. Mas, vamos ser mais praticos e colocar algum codigo:
Esse componente, BindableTextField pode ser adicionado ao Matise, não (Oh Ronaaaaaald!)? Agora, na vc pode ou:
1. Criar uma nova interface para dizer que a Window, Frame, Dialog, etc sabe como tratar com os bindables dentro dela - isso pode ser feito com reflection/introspection de uma maneira relativamente automatizada;
2. Criar o mecanismo de bind a parte, e usa-lo nos event listeners.
Sugestões?
valeuz...
Oi oi oi!!
Você pode sim adicionar componentes à paleta, e isto é extremamente simples. Eu só tive um problema com componentes customizados, que foi o cache. O mecanismo da paleta foi feito para componentes prontos (estáveis), não para componentes que você está desenvolvendo atualmente. Por isso, se você gerou um .jar com um componente, o importou para a paleta, depois regerou o .jar com modificações, estas modificações só vão aparecer se você reiniciar o Netbeans (talvez precise apagar o diretório /var/cache tb, mas eu acho que não). Bom, de qualquer forma, acho que seria boa prática colocar na paleta apenas componentes no mínimo testados e funcionando, de qualquer forma.
Quando à sua idéia da interface Bindable, eu usaria uma outra abordagem, mais parecida com a da conversão de tipos do WebWork. Eu criaria uma interface Binder, cujas implementações pegariam o componente original (padrão do swing) e aplicariam o binding sobre ele. Daí, bastaria você criar implementações de Binder para JTextComponent, JComboBox, SeuComponenteDeGraficoDeTorta, etc., e mapeá-las em algum arquivo de configuração. Quando o engine encontrasse um JTextField, buscaria nessa configuração qual o Binder apropriado e o aplicaria. Deste modo, você não precisaria criar uma subclasse para cada componente, apenas para fazer o binding. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Eu já usei o jGoodies Binding em um projeto, e realmente ele funciona!
O problema é que ele dá um trabalho extra, porque você tem que adicionar lógica para cada setter dos beans lançar PropertyChangeEvents. Isso porque ele faz o binding two-way, quero dizer, se você modificar o componente, ele atualiza o bean, se você modificar o bean, ele atualiza o componente.
Isso é bom pra alguns casos (telas de monitoração, por exemplo, que têm que exibir as alterações em tempo real), mas isso acrescenta uma complexidade que muitas vezes não compensa.
Já o subprojeto databinding do JDNC usa outra abordagem, a de que apenas os componentes atualizam o bean, não o inverso.
A vantagem é que o binding fica bem mais simples, porque você não precisa fazer nenhuma alteração mística nos seus beans. Nos casos onde você não precisa de atualização 'two-way' (que é o caso de formulários, creio eu), ele pode ser bem mais vantajoso. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Quando à sua idéia da interface Bindable, eu usaria uma outra abordagem, mais parecida com a da conversão de tipos do WebWork. Eu criaria uma interface Binder, cujas implementações pegariam o componente original (padrão do swing) e aplicariam o binding sobre ele. Daí, bastaria você criar implementações de Binder para JTextComponent, JComboBox, SeuComponenteDeGraficoDeTorta, etc., e mapeá-las em algum arquivo de configuração. Quando o engine encontrasse um JTextField, buscaria nessa configuração qual o Binder apropriado e o aplicaria. Deste modo, você não precisaria criar uma subclasse para cada componente, apenas para fazer o binding.
Hohoho! Captei a vossa mensagem!
Então poderíamos criar um Presenter abstrato com métodos que permitem a interação com diferentes widgets de maneira indireta, já que as classes que fazem o bind atuam como Adapters para os componentes Swing originais. Isso não afetaria a aplicação do MVP.. muito bom!
Com isso, conseguimos também criar um tipo de mapeamento, onde conectamos um componente Swing a uma propriedade do bean. Dessa forma conseguimos popular a View através dos dados do Model e vice-versa.
Jean diz: kd o KISS? (Keep it simple...???) Achei que o padrão mais complica do que beneficia...
Vitor Fernando Pamplona diz: eu gostei pq vc pode testar os eventos via JUnit
Vitor Fernando Pamplona diz: isso realmente é muito bom!
Jean diz: um ponto bom ... Mas qtos negativos vc tem?
Vitor Fernando Pamplona diz: tp... o único negativo que eu vi, é um monte de set e get
Jean diz:
- Vc escreve mais código
- Tem que testar mais por causa disso (no entando pode testar unitariamente)
- Também pode errar mais
- Dependencia do Presenter com a estrutura "física" do Model ... achei isso muito ruim
- Os objetos parecem ter mais responsabilidades do que o MVC Normal... acho que o MVP pode ser melhorado, talvez incluindo mais camadas entre o Presenter e o Model
Vitor Fernando Pamplona diz: mais camadas
Jean diz: é, abstrair sempre ajuda a diminuir o acoplamento
foi o que veio a mente... existe um padrão chamado PAC - Presentation Abstraction Control... acho ele um pouco mais direto e mais simples que o MVP
Jean diz: procurando rapidinho no google:
Jean diz: http://www.vico.org/pages/PatronsDisseny/Pattern%20Presentation%20Abstra/ Jean diz: veja se não é mais simples e tão eficiente quanto
Vitor Fernando Pamplona diz: hum... porra vou ter que ler com mais calma... não entendi nada
Vitor Fernando Pamplona diz: ahhh
Vitor Fernando Pamplona diz: saquei
Jean diz: hehehe... dá uma procurada no Google, pra mim, esse é um dos melhores pattern para usar dessa forma (semelhante ao conceito do MVP)
Falando no PAC (já que o Vitor postou a conversa):
- O PAC é um pattern que se encaixa muito bem na filosofia do Swing:
"Presentation-Abstraction-Control also emphasizes levels of increasing abstraction, but the overall structure is a tree of nodes rather than a vertical line of nodes layered on top of each other". No Swing o que acontece é muito parecido com isso, onde você tem uma uma estrutura de elementos (objetos) interagindo no lugar de camadas bem delineadas.
No mais, nesse modelo, temos um conceito chamado "agente", que é capaz de interceptar os eventos gerados na View, despachá-los para um objeto mais especializado, criando um conjunto de entidades "cooperáveis".
Dei uma olhada em alguns sites e pelo que consegui entender, o PAC não parece ser a melhor opção em sistemas grandes. Se eu entendi bem, o código ficará muito complexo, pois, dependendo do tamanho do sistema, ocorrerá uma 'explosão de classes' de granularidade fina.. quem conhece melhor o PAC e puder dar uma explicada melhor.. pois eu ainda não entendi a proposta dele. Aliás, o PAC lembra bastante o HMVC _________________Daniel F. Martins
Gostei bastante deste exemplo. Acho que é um momento excelente para colocarmos nossos neurônios para funcionar.
Vamos simular uma situação real. Imagine um cliente para este software. Ele pede o seguinte:
Acho melhor que a tela principal contenha apenas a lista dos cadastrados e sempre que for adicionar ou editar, quero que abra uma nova janela para tal.
Como poderíamos fazer esta simples alteração da View mudando o mínimo de código possível?
Acho que todos no forum querem ver estas técnicas de programação como MVC, IOC, etc, aplicadas em situações reais do seu dia a dia.
Na minha opinião, para provar que esta separação de camadas está realmente boa, bastaria criar uma nova classe view e configurá-la no spring. _________________JavaFree.org
Eu ainda acho que o MVP é a solução ideal para lidar com esses imprevistos, como você mesmo disse no seu exemplo. Para fazer tal mudança, bastaria algumas poucas modificações. Com certeza essa pequena mudança daria muito mais dor de cabeça se o programa fosse implementado de forma diferente.
Porém, eu ainda não estou muito contente com a solução adotada no exemplo. Quer dizer, ela é boa, mas com certeza pode ser automatizada. Talvez utilizando instropecção/reflexão, um mecanismo de conversão de tipos, um esquema de binding, entre outras coisas, como já foram sugeridas por outras pessoas neste tópico.
Estou pensando com cuidado, pois pretendo construir algo nesse sentido.. mas enquanto eu não posto as minhas idéias, o pessoal poderia ir contribuindo com suas próprias idéias.
Po, eu tava olhando agora o MVP com mais atenção, e gostaria que voces me explicassem porque o View nao pode saber da classe Cliente, e contém todos os gets/sets relacionados ao objeto cliente. Eu quero chegar no seguinte raciocinio. Se eu adicionar um atributo a mais no cliente, eu preciso adicionar um par set/get na classe cliente e no meu view também. Eu noto que não há uma dependencia entre o View e o Model na teoria, mas na prática o View depende muito do Model. Seila, não era mais fácil o View receber um objeto cliente e trabalhar em cima dele? Elimina duas funções por atributo que a classe tiver. Agora, imaginem voces, a minha classe de 26 atributos. O meu view iria ter 52 gets/sets , e minha classe mais 52. Por favor alguem me explique que vantagem tem isso?
_________________Eu vou te deletar, te excluir do meu Orkuuuuut. Eu vou te bloquear no Eme Esse EEEEEEne. Nao me mande mais scraps nem e-mail, Pooower Point. Me exclua também, e adicione ele!!!!
Na verdade você pode utilizar o MVP seguindo essa abordagem que você citou. As palavras do mestre:
Martin Fowler
Another style of Model View Presenter allows the view to update itself from the model directly. In this case events are delegated from the view to the presenter, and the presenter updates the model as before. However instead of having the presenter update the view, the view draws its information directly from the model. This clearly simplifies the presenter and removes the need for the presenter to be dependent upon the view, or need an interface for manipulating the view. However the view now needs to have the logic to update itself fromt he model. If there's a close fit between the view and the model this may be reasonable, but if there's a significant difference then the view is in danger of losing its humility.
Ou seja, você pode fazer a view 'puxar' os dados do modelo, porém, por mais simples que isso seja, isso pode ser entendido como 'lógica de apresentação' também. E, como a lógica de apresentação fica no Presenter, não faria muito sentido deixá-la na view.
Caso você ainda prefira utilizar esta abordagem, uma dica do Fowler:
Martin Fowler
A way to prevent this is to create an adapter that performs the translation from the base model class to that needs of the view.
Conclusão: não se deve colocar código nenhum na View que não seja o código responsável por renderizar a tela e criar os hooks para que o Presenter faça as devidas modificações.
Bom, pelo menos foi isso que eu entendi _________________Daniel F. Martins
Já comecei a escrever o tal do framework MVP... estou terminando a parte de Binding (falta criar adaptadores pro JList e JTable). Um resumão do funcionamento do Binding pode ser lido aqui.
PS: Já estou conversando com uma pessoa que já implementou coisa parecida, em Delphi. Já me deu várias dicas, baseado na experiência que ele teve. Obrigado mesmo!! _________________Daniel F. Martins
Ótimo este artigo, estou utilizando como referência no desenvolvimento do meu sistema. Artigo bem explicado, objetivo e de fácil entendimento.
Depois desse artigo eu vi que eu só programava estilo POG, agora chega de gambiarra... hahaha Muito obrigado, parabéns. _________________[color=darkblue]>[/color]
-
Novo no fórum e quer postar o código fonte? De uma olhada: Tag CODE do fórum -
"Compartilhe seu conhecimento..."
vfpampPosts:6098
E aih galera gostaram do artigo?
Muito bem escrito e montado pelo Daniel, parabéns fera!
_________________Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
carlsonwfPosts:38
Um problema que eu vejo tanto no MVP como no MVC é a passagem de dados entre o View e o Model. Vejam só: tenho uma tela por exemplo com 26 JTextFields e um JTable para efetuar uma pesquisa. Para mapear meu objeto eu preciso de 26 textFieldXXX.setText(meuObjeto.getAtributoXXX) e mais 26 para fazer o contrario, ou seja, popular meu objeto. Será que usando algum framework de binding eu estaria "ferindo" esse pattern? Qual a maneira, dentro de padroes, mais completa que voces acham que há?
Abração!!!
_________________Eu vou te deletar, te excluir do meu Orkuuuuut. Eu vou te bloquear no Eme Esse EEEEEEne. Nao me mande mais scraps nem e-mail, Pooower Point. Me exclua também, e adicione ele!!!!
vfpampPosts:6098
Poisé Carlos esse problema realmente existe. É muito set e get para pouca lógica. Mas não vejo como uma solução de bind como uma quebra de pattern, ela apenas está carregando tudo automaticamente. Basta que siga as "exigências" do pattern. Exemplo:
Carregar via reflection todos os componentes que possuem o mesmo nome que os atributos do modelo. (Solução interessante).
Acho realmente que MVP é o mais "correto" para ser utilizado pelo pessoal que desenvolve interfaces, pois foi feito para isso. Tratamento de eventos, lógica de apresentação e etc.
_________________Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
TriTonEPosts:1576
A solução do Vitor é bem interessante.. podemos até fazer algo parecido pra testar.
Mas não acho que a necessidade de criar os métodos acessadores seja um problema.. assim como as IDEs hoje dispõem de opções do tipo 'Encapsulate Fields', pra gerar os get() e set() da classe, podem existir plugins que criem esses 'ganchos' automaticamente para nós (essa feature no NetBeans ficaria saborosa!)...
_________________Daniel F. Martins
vfpampPosts:6098