Arquitetura Swing + DAO + MVC 'diferenciado' proposto pela oracle

JavaBaby Membro desde: 25/09/2010 20:02:09 Mensagens: 88 Offline

Eae galera, vai aí uma pergunta pra quem conhece bem os padrões DAO, Observer, MVC e swing! Sei que é uma pergunta cansativa, então sinta-se a vontade para responder ou não =)

Estou acostumado a trabalhar com Java Web, e implementar o padrão MVC nunca foi problema, tanto usando Servlets quanto outro framework MVC (como Struts ou JSF). Porém, comecei a desenvolver uma aplicação swing, e me deparei com algumas dificuldades implementando este padrão.

Com base nesta implementação "diferenciada" MVC, disponível no site da oracle: http://www.oracle.com/technetwork/articles/javase/mvc-136693.html

Notei que ele propõe fortemente o uso do padrão observer (listeners) para deixar a arquitetura flexível entre a camada Model - View;

1- uma ação é tomada no formulário (clique de um botão, propriedade de um campo mudada, enfim)
2- o formulário executa um método do controlador
3- o controlador itera todos os beans que estão observando ele, e toma a ação necessária (muda o valor de uma propriedade do bean)
4- ao mudar uma propriedade do bean, o bean alerta todos os controllers observadores
5- os controllers observadores alertam todos os formulários observadores

Esta arquitetura é perfeita em uma aplicação que não tem banco de dados! Os formulários serão sempre notificados sobre as mudanças de outro, ou seja, posso ter vários formulários abertos compartilhando um bean, e ao mudar uma propriedade deste bean, todos os formulários serão atualizados.

Porém, ao adicionar a camada DAO, segue o problema: o Bean em sí, terá apenas papel de um transfer-object, ou seja, ele muitas vezes não representará a informação que eu quero que os formulários sejam notificados (por exemplo, em um formulário que tenha uma grid, eu quero que um List de beans sejam delegados a ela, não um único bean).

A solução que estou pensando é: adicionar uma nova camada ao software, na qual tenha componentes que representem as informações da tela (similares aos backing beans do JSF), sendo que estes seriam os objetos a serem amarrados na lista de observadores.

Se alguém puder me esclarecer se esta é uma solução é a viável, agradeço!

JavaBaby Membro desde: 25/09/2010 20:02:09 Mensagens: 88 Offline

Ou até o próprio DAO, pois caso algo aconteca ao banco de dados, quero que minhas grids sejam atualizadas!

This message was edited 1 time. Last update was at 05/02/2012 19:18:22

Faz uns 3 anos que eu larguei o desktop (amem), na epoca eu tinha o mesmo problema. Um tempo atrás eu vi um pessoal falando sobre o padrão MVP, ainda não tive tempo para implementar pra saber se realmente funciona, mas não custa olhar: http://blogs.infragistics.com/blogs/todd_snyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx

Não necessáriamente você tem que usar Observer em tudo quanto é lugar, observer até onde eu lembro (posso estar enganado) você usa quando tem a necessidade notificar objetos que queiram saber da sua mudança de estado (sem alto-acoplamento). No livro use a cabeça: design patterns tem um exemplo excelente.

Vou acompanhar este tópico que também estou curioso

[]'s

edit: pede pro moderador mudar este tópico para o forum de arquitetura que acho que você obterá respostas mais rápidas

GUJ Ranger Membro desde: 20/03/2007 00:00:57 Mensagens: 974 Offline

Eu trabalho apenas com Desktop e gosto de desenvolver apenas para Desktop(amem, amem)....

Um bom exemplo, que sempre recomendo em MVC com Desktop e este aqui: http://mballem.wordpress.com/2011/02/21/utilizando-swing-com-banco-de-dados/

t+ e boa sorte.

JavaBaby Membro desde: 25/09/2010 20:02:09 Mensagens: 88 Offline

WRYEL wrote:Faz uns 3 anos que eu larguei o desktop (amem), na epoca eu tinha o mesmo problema. Um tempo atrás eu vi um pessoal falando sobre o padrão MVP, ainda não tive tempo para implementar pra saber se realmente funciona, mas não custa olhar: http://blogs.infragistics.com/blogs/todd_snyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx

Não necessáriamente você tem que usar Observer em tudo quanto é lugar, observer até onde eu lembro (posso estar enganado) você usa quando tem a necessidade notificar objetos que queiram saber da sua mudança de estado (sem alto-acoplamento). No livro use a cabeça: design patterns tem um exemplo excelente.

Vou acompanhar este tópico que também estou curioso

[]'s

edit: pede pro moderador mudar este tópico para o forum de arquitetura que acho que você obterá respostas mais rápidas

Sim, eu já li este livro do head first, muito bom, recomendo!

E confirmo, só preciso implementar o padrão observer quando quero que certos objetos (os observers/listeners) tomem certa ação (executem método x) quando a propriedade de certo objeto seja alterada (o subject/observado).

Mas seria bom implementar esse padrão em todos os componentes (ou pelo menos maioria), pois pensei na seguinte possibilidade (Considerando que minha aplicação desktop poderá ter multiplas janelas abertas ao mesmo tempo):

-O usuário tem as janelas "Cliente" e "Contas a receber" abertas, sendo que as informações da janela de "Contas a receber" são dependentes das informações de "Cliente" (cada conta a receber pertence a um cliente).
-O usuário, na janela de "Cliente", altera o nome de um cliente.
-O controller alerta os listeners (que no caso, seria a janela "Contas a receber") de que algo em "Cliente" foi alterado".
-A janela "Contas a receber" altera automaticamente o nome do cliente que foi alterado, sem deixar nenhuma informação inconsistente.

Conclusão: estou quase fazendo dos DAOs os subjects (objetos a serem observados). Ao ser chamado o método update, insert, delete ou qualquer outro que modifique as informações que outros formulários serão dependentes, todos estes dependentes serão notificados. E também, apenas implementarei o padrão observer do lado View observa Model, não Model observa View como proposto no link que disponibilizei (pois ao alterar o estado de uma View, não haverá necessidade de multiplos DAOs serem notificados).

JavaBaby Membro desde: 25/09/2010 20:02:09 Mensagens: 88 Offline

fernandopaiva wrote:Eu trabalho apenas com Desktop e gosto de desenvolver apenas para Desktop(amem, amem)....

Um bom exemplo, que sempre recomendo em MVC com Desktop e este aqui: http://mballem.wordpress.com/2011/02/21/utilizando-swing-com-banco-de-dados/

t+ e boa sorte.

Este exemplo é como estava desenvolvendo antes de ver o aquele MVC proposto pela Oracle.

Porém, teria problemas em situações como esta:

-O usuário tem as janelas "Cliente" e "Contas a receber" abertas, sendo que as informações da janela de "Contas a receber" são dependentes das informações de "Cliente" (cada conta a receber pertence a um cliente).
-O usuário, na janela de "Cliente", altera o nome de um cliente.
-O controller alerta os listeners (que no caso, seria a janela "Contas a receber") de que algo em "Cliente" foi alterado".
-A janela "Contas a receber" altera automaticamente o nome do cliente que foi alterado, sem deixar nenhuma informação inconsistente.

GUJ Ranger Membro desde: 20/03/2007 00:00:57 Mensagens: 974 Offline

chimufox wrote:

fernandopaiva wrote:Eu trabalho apenas com Desktop e gosto de desenvolver apenas para Desktop(amem, amem)....

Um bom exemplo, que sempre recomendo em MVC com Desktop e este aqui: http://mballem.wordpress.com/2011/02/21/utilizando-swing-com-banco-de-dados/

t+ e boa sorte.

Este exemplo é como estava desenvolvendo antes de ver o aquele MVC proposto pela Oracle.

Porém, teria problemas em situações como esta:

-O usuário tem as janelas "Cliente" e "Contas a receber" abertas, sendo que as informações da janela de "Contas a receber" são dependentes das informações de "Cliente" (cada conta a receber pertence a um cliente).
-O usuário, na janela de "Cliente", altera o nome de um cliente.
-O controller alerta os listeners (que no caso, seria a janela "Contas a receber") de que algo em "Cliente" foi alterado".
-A janela "Contas a receber" altera automaticamente o nome do cliente que foi alterado, sem deixar nenhuma informação inconsistente.

Eu nao sei como vc desenvolve, mas eu uso listeners apenas para retorno de valores como por exemplo uma consulta qquer. Seria mais ou menos isso, veja.

//inicia listener(ouvinte) de cliente
    private ArrayList<ConsultaClienteListener> listeners = new ArrayList<ConsultaClienteListener>();

public interface ConsultaClienteEvent{
        public List<Clientes> getListaClientes();
        public Long getCodigoCliente();
    }

public interface ConsultaClienteListener{
        public void clienteSelecionado(ConsultaClienteEvent e);
    }
    
    public void addListener(ConsultaClienteListener listener){
        if(!listeners.contains(listener)){
            listeners.add(listener);
        }
    }
    
    private void notifyListeners(final List listaClientes, final Long codigoCliente){
        ConsultaClienteEvent e = new ConsultaClienteEvent() {
            @Override
            public List<Clientes> getListaClientes() {
                //throw new UnsupportedOperationException("Not supported yet.");
                return listaClientes;
                
            }
            
            public Long getCodigoCliente(){
                return codigoCliente;
            }
            
        };
        
        for(ConsultaClienteListener cl : listeners){
            cl.clienteSelecionado(e);
        }
        
    }

Uso esse ouvinte para retornar valores das consultas apenas, como disse nao sei como vc trabalha com seus ouvintes ou o que precisa e tals.....Eu trabalho apenas com Desktop e nao tenho problema algum tanto a nivel de banco como a nivel de aplicacao.

t+ e boa sorte.

chimufox wrote:A solução que estou pensando é: adicionar uma nova camada ao software, na qual tenha componentes que representem as informações da tela (similares aos backing beans do JSF), sendo que estes seriam os objetos a serem amarrados na lista de observadores.

A principio vale o bom senso. Na minha opinião haverá momentos que criar uma estrutura de dados associada a view será uma boa saida porem haverá momentos que fazer como o fernandopaiva indicou (ver o blog) ficara mais simples e de bom tamanho.

A complexidade das funcionalidades é que alavanca as estratégias e os padrões a serem aplicados, portanto não precisa ser a mesma solução para todas.

flws

GUJ Ranger Membro desde: 20/03/2007 00:00:57 Mensagens: 974 Offline

fantomas wrote:

chimufox wrote:A solução que estou pensando é: adicionar uma nova camada ao software, na qual tenha componentes que representem as informações da tela (similares aos backing beans do JSF), sendo que estes seriam os objetos a serem amarrados na lista de observadores.

A principio vale o bom senso. Na minha opinião haverá momentos que criar uma estrutura de dados associada a view será uma boa saida porem haverá momentos que fazer como o fernandopaiva indicou (ver o blog) ficara mais simples e de bom tamanho.

A complexidade das funcionalidades é que alavanca as estratégias e os padrões a serem aplicados, portanto não precisa ser a mesma solução para todas.

flws

fantomas: Exato, falou pouco mas falou muito.....Como eu disse, eu só desenvolvo em J2SE ja faz 5 anos, e nunca tive problemas, tanto usando Listeners como Acoplamento, nenhuma das técnicas nunca falhou...Sou acostumado a usar muito recursos de banco como triggers,views,procedures,functions etc....Deixo para cada um banco ou app, cuidarem de si proprios, acho meio sem sentido uma aplicacao ficar dando inserts/updates pq não o banco cuidar disso ??? Exemplo: Insiro um novo cliente e ao inserir é disparado uma trigger para criar uma conta(receber), é apenas um exemplo simples mas é como prefiro trabalhar.

Como disse fantomas: "A complexidade das funcionalidades é que alavanca as estratégias e os padrões a serem aplicados".

t+ e boa sorte.

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