Arquitetura de uma aplicação Swing

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Então Maurício e Philip...

O jeito é deixar o Xwork de lado! É melhor minha camada de controle chamar logo o façade. Fdss.. os Commands e todo aquele amontoado de configurações xml que ia ter que fazer no XWork!!! Se por acaso eu decidir criar um cliente web é só usar o webwork (que já usa o xwork internamente).. e daí sim eu ficaria preso aos commands... mas agora com o toque q vcs deram conclui que commands não não necessários.

Bom.. concluindo, em Swing descobri que não é necessário mais usar commands, criando assim uma arquitetura mais elegante...

Mas já em um aplicação web vou ter que imaginar uma forma de extinguir com os commands e actions também! Mas sem perdem alguns dos benefícios que são proporcionados pelos frameworks...

aiaiai... bom.. já estou com dúvidas de novo... Mas dane-se esta dúvida (não preciso disso agora.. hehehe), e danem-se os commands!

Abraços!
Thiago

Homi, tenha calma, você tá revoltado demais

Você vai continuar usando Commands em Swing (você pensa que um ActionListener é o que?) pra reunir as informações da interface gráfica e chamar o seu façade. Porque os componentes Swing não tem como advinhar qual método chamar no seu façade.

E nas aplicações web vai ser a mesma coisa, você vai continuar usando commands pra reunir as informações e poder chamar o façade.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

humm.. é...

Mas imagine se minha aplicação tivesse que chamar o action listener, que chama o command (IncluialunoCommand por exemplo) que chama o façade!

Agora vai ficar: Chama action listener que chama façade!

Bom.... talvez o próprio action que extende o action do xwork poderia atuar como action listener... mas ainda sim vc vai ter que ficar configurando aquele monte de arquivo xml!

A coisa agora só começa a complica por que não poderei usar IoC ou a validação do XWork....

Abraços!
Thiago

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Olá!

Considerando que a minha aplicação agora tem a seguinte arquitetura:

view --> actionListener (atuando como controle) --> façade --> pojo -- dao

É conveniente eu colocar a validação de dados no façade? Hoje fiquei o dia inteiro pensando em validação e como fazer um controle descente!

Bom, IMHO, acho que a validação deveria ficar no controle, e fora da camada de aplicação. Ou seja, quando lançar um evento de botão por exemplo, será chamado o controle, que validação os dados inseridos pelo cliente, cria a representação do modelo e os envia para o façade! Acho que se deixar essa validação no controle é mais flexível para tratar diferentes formas de dar um feedback da operação para o usuário.
O que vocês acham? É isso mesmo?

Outra perguntinha... vcs acham que não há problema em usar o padrão Observable (java.util.Observable) para notificar a view quando houver alterações no modelo? Quando a aplicação é somente swing, acredito que não há problema, mas e se eu quiser reaproveitar o mesmo modelo para uma aplicação com client web?

Hoje fiquei o dia inteiro me questionando sobre essas coisas. Pesquisei pacas antes de perguntar isso aqui no GUJ! Tive muitas outras duvidas que foram sanada com a ajuda do google, portanto, felizmente testeni colocar aqui só as duvidas realmente dignas para este tópico!

Desde já agradeço!
Thiago

Dae Thiago,

Pq nao da uma olhadinha no JForms?

]['s

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

fabgp2001 wrote: Dae Thiago,

Pq nao da uma olhadinha no JForms?

]['s

E ai Fábio! Eu já olhei!!!

Tentei encontrar nele alguma coisa que tirasse essas dúvidas! Daí eu abaixei aquelas duas aplicações exemplo que vcs criaram para enteder como ele é usado! Achei bastante interessante! Mas Fábio, confesso pra vc que por enquanto estou tentando fugir das configurações XML! Isso por que a aplicação que estou fazendo ainda é pra aprender e principalemente para me aprofundar bém nos conhecimentos de arquitetura swing!

Também dei uma olhada no JGoodies, e depois preciso olhar com calma o genesis!

Outra coisa Fábio! Por que vocês não extenderam o Xworks para criar o JForms?

Abraços!
Thiago

Virtual Machine Man Membro desde: 21/08/2002 03:53:28 Mensagens: 661 Offline

Meu, que pena que so deu pra olhar essa thread agora...

Tava la atras na discussao um uso de commands:

structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions.

Ninguem precisa de commands. Commands tem pros e contras, vc sempre tem um compromisso. Em todos os comentarios do pcalcado existe a suposicao de que os comamnds vao ficar em cima da camada de aplicacao, se eu entendi direito.

Mas os commands podem ser usados pra mais do que apenas ponteiro de funcao, e mais do que apenas ParameterObject. Eles podem ser uma forma consistente de chamar uma funcao que a camada de baixo nao conhece. Esse eh o ponto onde eles brilham.

Voce so consegue entender o command se olhar pro executor:

Bom, eu omiti o bloco finally onde vc fecha a transacao, o socket, etc. Seu command pode fazer muitas suposicoes sobre o estado dos dados.

Thiago, se vc quiser fazer view em Swing, vc vai ter que usar o padrao Command mesmo que vc nao seja explicito:

Esse eh um jeito consistente de executar coisas na thread certa (AWT Dispatcher), sem saber o que eles fazem.

Claro que o seu command nao vai ter a logica, ele tem que ter um comando, uma ordem. Ele nao faz nada, manda fazer.

Bom, vou ficar por aqui, pq eu ja falei pra uma semana!!

Abracos!

Virtual Machine Man Membro desde: 21/08/2002 03:53:28 Mensagens: 661 Offline

"Brevity is the soul of wit". Acho que eu devia mudar minha sig.

This message was edited 1 time. Last update was at 10/06/2005 07:22:37

Duke,
No caso especifico citado pelo Thiago, ele queria usar Commands como um framework MVC geralmente o faz, como dispatch. Em 99% dos casos, logica de negocio acaba dentro dos commands, que por si so sao inuteis neste contexto.

A sua estrategia para uso de Commands e legal, mas nao e nada que nao se consiga com Strategy, polimorfismo e delegaçao pura e simples.

Commands tem seu uso para transformar algoritmos em entidades ou value object num dominio, ou para prover undo e outras coisas (como journals que o Prevayler faz). Nao deveriam ser utilizados em 10% do que sao hoje.

Shoes

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Quanto aos Commands, o que eu pensava em fazer com ele é realmente como o Shoes citou! Eu queria um controle que usasse commands que pudesse ser fácilmente usando tanto em Swing como numa aplicação web. Mas pelo que me passaram e pelo que antei estudando, o controle está intimamente ligado à view!

Entendi que a lógica da aplicação deve estar sendo executada em outros pontos que não fosse o command. Assim o código fica mais fácil de aproveitar indiferentes de qual view vc está usando.

Um dos objtivos da camada de controle é definir qual será a próxima view que deverá ser visualida, nao é? Daí o motivo dela ser tão dependente do controle!

Quando o Maurício Linhares falou num dos posts acima que por mais que eu tentasse fugir dos actions eu não conseguiria, afinal, vc deve implementar o commandListener (ou command action.. esqueci o nome), já estamos usando uma action. Ou seja, eu não preciso chamar um command action para então chamar um outro command, que poderia ser por exemplo um command do xwork!

Uma dúvida recente que tive e que não está completamente solucionada é: Realmente devo controlar a tranzação no controle? Ou controle a tranzação no DAO?

Por exemplo, se o controle da tranzação fica no controle, como vc faz para saber se a persistência que vc está fazendo é em um MySQL, PostgreSQL, XML, Arquivo e etc...???

Abraços!
Thiago

Thiago Senna wrote:
Uma dúvida recente que tive e que não está completamente solucionada é: Realmente devo controlar a tranzação no controle? Ou controle a tranzação no DAO?

Por exemplo, se o controle da tranzação fica no controle, como vc faz para saber se a persistência que vc está fazendo é em um MySQL, PostgreSQL, XML, Arquivo e etc...???

Se a transação envolve todo o sistema, e não apenas lá o SGBD, você deve cudiar de transações em um lugar acima dos DAOs. Do contrário você só tem transacionamento para persistência.

Shoes

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

pcalcado wrote:

Thiago Senna wrote:
Uma dúvida recente que tive e que não está completamente solucionada é: Realmente devo controlar a tranzação no controle? Ou controle a tranzação no DAO?

Por exemplo, se o controle da tranzação fica no controle, como vc faz para saber se a persistência que vc está fazendo é em um MySQL, PostgreSQL, XML, Arquivo e etc...???

Se a transação envolve todo o sistema, e não apenas lá o SGBD, você deve cudiar de transações em um lugar acima dos DAOs. Do contrário você só tem transacionamento para persistência.

Shoes

E o que seria em cima dos DAO's??? Seria por exemplo eu utilizar um Façade para acessar os DAO's?

Thiago

Seria. Use um Session Value Holder Factory Delegate para guardar a implementacao do Factory Delegate, que te da um Business Facade que esconde um Session Facade que delega pra um Singleton Data Access Object. Pra esse ultimo Facade voce passa uma serie de Data Transfer Objects inicializados pelo seu Business Delegate, que eh chamado pelo Front Controller e validado pelo Controller. Dai, eh soh pegar o Plumb Projectile Thrower Facade, apontar pro Inferior Limb Delegate, e disparar.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

cv wrote:Seria. Use um Session Value Holder Factory Delegate para guardar a implementacao do Factory Delegate, que te da um Business Facade que esconde um Session Facade que delega pra um Singleton Data Access Object. Pra esse ultimo Facade voce passa uma serie de Data Transfer Objects inicializados pelo seu Business Delegate, que eh chamado pelo Front Controller e validado pelo Controller. Dai, eh soh pegar o Plumb Projectile Thrower Facade, apontar pro Inferior Limb Delegate, e disparar.

Oloco meu!

Posta um exemplo ai!!!

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Olá GUJ's...

Relaxem que não vou perguntar neste post sobre este assunto...

Estou lendo este livro aqui
que tem nada a ver com swing... mas me fez entender melhor o que vcs tanto tentaram dizer nos posts anteriores, inclusive este em específico:

cv wrote:Seria. Use um Session Value Holder Factory Delegate para guardar a implementacao do Factory Delegate, que te da um Business Facade que esconde um Session Facade que delega pra um Singleton Data Access Object. Pra esse ultimo Facade voce passa uma serie de Data Transfer Objects inicializados pelo seu Business Delegate, que eh chamado pelo Front Controller e validado pelo Controller. Dai, eh soh pegar o Plumb Projectile Thrower Facade, apontar pro Inferior Limb Delegate, e disparar.

Cara meu... eu realmente estava dominado pelo lado negro da força! Tinha tomado uma overdose de design patterns e não conseguia imaginar um projeto mesmo que simple que não usasse essas merdas...

Também separei um tempo para dar uma olhada em alguns projetos open source e vi como se dá para resolver a maior parte dos meus problemas usando POJO... Agora só falta mesmo é experiência...

Valeu GUJ's!
Thiago

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