Arquitetura de uma aplicação Swing

[quote=pcalcado][quote=Thiago Senna]
Bom…
Mas onde ficam minhas chamadas ao DAO? Dentro dos POJOS??
[/quote]

Você precisa de DAO para testar regra de negócio? Está construindo o que, um driver JDBC?

Chamadas ao DAO geralmente ficam em camadas de aplicação.[/quote]

Eis que se começa mais uma aula onde me encontro completamente perdido! :mrgreen:

Concordo com você Philip! Não é necessário usar DAO para testar a camada de negócio… concordo plenamente… e é assim que deve ser, em minha opinião!

Até onde sei, o Command tem o método execute, e neste método execute o pessoal costuma fazer isso, por exemplo:

public void execute(String ident) {

AlunoDAO dao = new AlunoDAO(); // 1
Aluno a = dao.load(ident); // retorna um aluno


double media = a.calculaMedia();
System.out.println(media);

}

O exemplo acima é escrotinho, mas da para discutir em cima dele rsrs…
Por exemplo, para testar o método calculaMedia da classe Aluno eu não dependo do DAO. Até aqui tudo bém.

Mas suponde que tenho dois clientes, um swing e outro web! Se houver uma operação chamada calcula média, basta chamar este command e passar a identificação do aluno por parâmetro! Então, de uma maneira ou de outra, acho que é possível reaproveitar este command para diferentes clientes… mas é claro, depende muito da arquitetura das duas aplicações…

Mas para realizar uma operação onde eu busco um determinado aluno do banco à partir de sua identificação, eu dependo do DAO. Se eu quiser testar esta operação, testar aqui no command não é mais simples? Ou testar em um outro pojo qualquer é mais fácil também! Melhor colocar este código no command ou pojo para os íntimos do que em um session bean ou servlet!

humm…

Philip, com a colocação que vc está fazendo, estou entendo é que deveríamos fazer isso:

Aluno a = new Aluno();
a.load(ident);
double media = a.calculaMedia();
System.out.println(media);

Acabei de mover a lógica de acesso ao banco para dentro do método load da classe Aluno. Foi isso que entendi quando vc escreveu

No meu entender, nos dois exemplo que citei a lógica de negócio está dentro do POJO.

Um exemplo orroroso em minha opinião seria isso aqui: Sentem-se para não cairem de costas… e não façam isso em casa!!

[code]
public void execute(String ident) {

AlunoDAO dao = new AlunoDAO(); // 1
Aluno a = dao.load(ident); // retorna um aluno

double media = a.getMedia1() + a.getMedia2() + a.getMedia3() + a.getMedia4();

media /= 4;

System.out.println(media);[/code]

Agora sim a lógica de negócio não está dentro do POJO.
Afinal, no primeiro exemplo que citei, o que há de errado??? O que poderia ser melhorado??? :wink:

Abraços!
Thiago

Opa! Peraí!

Objetos do domínio fazendo acesso ao banco de dados? Oh, não! :smiley:

Você não precisa dos DAOs pra testar as regras de negócio, porque persistir os objetos em um lugar qualquer não faz parte das regras de negócio.

Você testa as regras de negócio só com objetos do domínio e testa os DAOs lá na persistência, com o banco de dados ou seja lá o que for que você for usar.

1- Por que você está usando Command? O que ele te provê que é tão especial assim? Imagina que eu tenho 50 operações, eu teria que criar 50 commands.

2 - POJO não necessariamente é um objeto de negócio, eu falei besteira, na verdade o que eu quis dizer é para você tirar a lógica do Command e colocar na camada de aplicação, não na entidade

Shoes

[quote=Maurício Linhares]Opa! Peraí!

Objetos do domínio fazendo acesso ao banco de dados? Oh, não! :smiley:

Você não precisa dos DAOs pra testar as regras de negócio, porque persistir os objetos em um lugar qualquer não faz parte das regras de negócio.

Você testa as regras de negócio só com objetos do domínio e testa os DAOs lá na persistência, com o banco de dados ou seja lá o que for que você for usar.[/quote]

Humm… entaum blz. Gostei da sua colocação:

“persistir os objetos em um lugar qualquer não faz parte das regras de negócio.”

Acho que agora tá blz… Bastante monstruoso aqueles exemplos que passei hein… hehe rsrs…

[quote] 1- Por que você está usando Command? O que ele te provê que é tão especial assim? Imagina que eu tenho 50 operações, eu teria que criar 50 commands.

2 - POJO não necessariamente é um objeto de negócio, eu falei besteira, na verdade o que eu quis dizer é para você tirar a lógica do Command e colocar na camada de aplicação, não na entidade [/quote]

Oi!

Quanto a resposta de número 1.

Agora compreendo! De acorodo com sua colocação, e pensando bém no caso, realmente é meio orroroso criar 50 commands, um para cada operação. Essa sua colocação se completou mais ainda com sua colcação de número 2.

Quanto a resposta de número 2.

Entendi Philip… não preciso necessariamente de um command para colocar as lógicas de operações dos usuários. Posso então usar um POJO qualquer. Acho que faz mais sentido, afinal, isso torna até possível reaproveitar pedaços de operações.

Gosei do fato de vcs terem repudiado o exemplo onde fiz com que a entidade acessasse a base de dados. Agora tenho certeza de que isso não é bém vindo!

Para finalizar, como vcs tem organizado essas operações em seus POJOS? Usam alguma regra de nomenclatura, pacotes???

Vcs tem um bom artigo ou livro para indicar?

Abraços!
Thiago Senna

Desculpem por reiniciar esta Thread!

Estou querendo desenvolver uma aplicação onde as tecnologias empregadas nas camadas são:

View - Swing
Controle - XWork (Commands)
Persistencia - Hibernate

Mas como discutido nesta Thread, parece haver opções melhores, bém melhores que usar commands. Meu objetivo com este post é exatamente fugir finalmente deles, mas houve uma colocação muita boa do shoes, que na hora em que fui pensar em como colocar isso na prática surgiram algumas dúvidas. A colocação foi a seguinte

Afinal, o que seria a camada de aplicação? Por acaso camada de aplicação é o mesmo que Domain Model? (Acho que naum…)

Surgiu esta dúvida pra mim pelo seguinte. Temos as camadas view, controle e modelo, e para os íntimos, persistência, mas não imagino onde ficaria a lógica de aplicação.

Por acaso isso seria um façade + modelo?

Façade >> Modelo

Ou é um objeto que agrupa funcionalidades em comum que acontecem entre as entidades do modelo?

Abraços!
Thiago :slight_smile:

Bull’s Eye! :thumbup:

Aí os commands do XWork vão fazer contato com a sua façade pra poder invocar a aplicação, no dia que der uma doida e você quizer refazer tudo com um outro framework, você vai reaproveitar o seu façade todo, só vai ter que refazer o código que junta as informações pra enviar pro façade.

E não faça um único façade pra tudo também não, dê uma dividida.

Opa… valeu…

Aproveitem e tirem mais uma dúvida! A tranzação deve iniciado já dentro do Façade, ou no controle?

Ou seja, quando eu emcapsulo as operaçoes dentro de um façade eu também emcapsulo a tranzação?

Pergunto isto pelo seguinte! Se for para usar façade junto com uma aplicação Swing, não preciso usar commands! Isso só estaria adicionando complexidade no meu código. É isso mesmo?

Abraços!
Thiago

e em que situacao vc precisaria de commands?

[quote=Thiago Senna]Opa… valeu…

Aproveitem e tirem mais uma dúvida! A tranzação deve iniciado já dentro do Façade, ou no controle?

Ou seja, quando eu emcapsulo as operaçoes dentro de um façade eu também emcapsulo a tranzação?

Pergunto isto pelo seguinte! Se for para usar façade junto com uma aplicação Swing, não preciso usar commands! Isso só estaria adicionando complexidade no meu código. É isso mesmo?

Abraços!
Thiago[/quote]

A transação tem que estar emcapsulada no façade, o código que chama o façade não deveria ter que saber disso. E se você for usar o XWork vai ter que usar Commands sim, como é que você ia usar ele sem isso?

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… :wink: 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 :lol:

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.

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! :wink:
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

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! :wink:

Desde já agradeço!
Thiago

Dae Thiago,

Pq nao da uma olhadinha no JForms?

]['s

[quote=fabgp2001] Dae Thiago,

Pq nao da uma olhadinha no JForms?

]['s[/quote]

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

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

Tava la atras na discussao um uso de commands:

[quote]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.
[/quote]

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:

public Object execute(Command cmd) throws Throwable {
   // faz alguma coisa antes, por exemplo, iniciar uma transacao, abrir um socket, etc.
   cmd.execute(system); // roubei essa do Prevayler
   if (cmd.hasErrors()) {
      throw cmd.getThrowable();
   }
   else {
     return cmd.getResult();
   }
}

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:

SwingUtilities.invokeLater(new Runnable() {
  public void run() {...}
}

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!! :wink:

Abracos!

“Brevity is the soul of wit”. Acho que eu devia mudar minha sig. :stuck_out_tongue:

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

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