Olá pessoal, beleza pura com vcs?
Para WEB, temos o MVC, que é ótimo!
Agora, gostaria de receber dicas sobre como projetar bem uma aplicacao swing, como dividir visualizacao de negócios, etc…
Valeu!
Arquitetura de uma aplicação Swing
C
48 Respostas
Ora, usando MVC!
O MVC não pressupõe que você esteja montando um sistema pra web ou pra desktop.
Mas se o que você está procurando é um framework que ajude a simplificar o MVC em uma aplicação Swing, você pode testar o xWork http://www.opensymphony.com/xwork/ ou então o Spring RCP http://www.springframework.org/spring-rcp.
C
Me desculpem aí pessoal, esse tópico devia estar na parte relacionada a GUIs, mas sem querer coloquei aqui. Os moderadores poderiam transferir esse topico para o local adequado.
Olá,
Acredito que minha experiência seja parecida com a sua, pois eu sempre trabalhei com sistemas em Java para a WEB, porém no projeto que estou trabalhando atualmente é a primeira vez que eu trabalho com frontends em Swing (não desenvolvo as views, trabalho somente com o backend J2EE).
Estamos usando Swing pois o projeto exige que as interfaces humanas tenham um alto grau de usabilidade (estamos migrando um projeto já existente feito em Delphi), basicamente o usuário irá baixar os módulos através do Java Web Start.
Depois de uma boa garimpada pela Internet, cheguei a seguinte conclusão de arquitetura (no meu caso o sistema tem que ter fail-over,escalável, etc, consequentemente ele rodará em Cluster) :
Frontend Swing <> Business delegate <> Remote Façade <> POJO Business Logic <> iBatis DB Layer <> RDBMS
Frontend Swing - Minha camada de apresentação.
Business delegate - Resposável por interagir com a camada remota através de um Service Locator, por questões de performance, eu faço cache do EJBHome.
Remote Façade - Esse pattern foi Implementado com EJB (Session Beans Stateless), repare que eu não uso o Session Façade (pelo que eu entendi no livro no Martin Fowler a diferença básica entre ambos é que o Session Façade aceita lógica de negócios dentro dele, no meu caso eu deixo essa tarefa para Classes POJO , pois acima de tudo facilita os testes com o JUnit e não está acoplado a nenhum EJB)
POJO Business Logic - Onde se concentra a lógica de negócios, por estar concentrado em um POJO facilita o reuso, manutenção, testabilidade, etc. Eu implementei utilizando o Pattern Command, poderia usar também um Service Layer.
iBatis DB Layer - O framework que eu utilizo para a persistência de objetos, responsável por toda comunicação com o RDBMS, uma abordagem interessante para performance é utilizar o mecanismo de cache dele ou delegar para uma outra API (no meu caso eu utilizo o OSCache).
RDBMS - Utilizo o SQL Server 2000 para a persistência dos dados
As poucos eu estou refatorando essa arquitetura, mas acredito que seje um bom ponto de partida.
Espero telo ajudado.
[]s
Douglas
Ou deixar o design procedural de lado e usar um Domain Model 
POJO Business Logic - Onde se concentra a lógica de negócios, por estar concentrado em um POJO facilita o reuso, manutenção, testabilidade, etc. Eu implementei utilizando o Pattern Command, poderia usar também um Service Layer.
Ou deixar o design procedural de lado e usar um Domain Model ;)
Sim, com certeza pcalcado 
, como falei no meu último post, aos poucos eu estou refatorando a arquitetura …
Mas no geral, vc acredita que essa arquitetura é válida como ponto inicial ?
Mas no geral, vc acredita que essa arquitetura é válida como ponto inicial ?
Com a experiência de quem tem literalmente centenas de Commands para manter: não. 
Ainda pretendo fazer um post sobre como refatorar um elefante, mas posso adiantar o seguinte: Não escreva código novo como Command. Crie um domínio e vá utilizando ele toda vez que precisar corrigir bug ou acrescentar algo novo.
Shoes
Philip, esse suposto isolamento é ótimo se vc tem um sistema “normal”, digamos assim.Numa aplicação prevalente por possuirmos um único objeto raiz(Um verdadeiro Deus na aplicação), na qual todos os demais dependem(e haja nível de invaginação de objetos…), command ainda rula… :roll:
Philip, esse suposto isolamento é ótimo se vc tem um sistema “normal”, digamos assim.Numa aplicação prevalente por possuirmos um único objeto raiz(Um verdadeiro Deus na aplicação), na qual todos os demais dependem(e haja nível de invaginação de objetos…), command ainda rula… :roll:
Não deixa de ser irônico isso. A gente tem que quebrar o encapsulamento de uma classe para usar SGBDR, aí uma solução de “persistência transparente” exige que você modele seus algoritmos como Commands, destruindo seu Domain Model e criando código procedural… 
Cada vez mais eu acredito que persistência transparente em java só o dia que que a JVM for projetada para isso.
Cada vez mais eu acredito que persistência transparente em java só o dia que que a JVM for projetada para isso.
Acho que é a coisa que o Gavin King mais repete no Hibernate In Action, “paradigm mismatch”. Enquanto não houver um meio simples, escalável e rápido de se persistir e buscar “objetos” da linguagem, não tem jeito.
Eu acho que a persistência em cascata e a navegação de grafos no Hibernate são de uma ajuda imensa, mas o RDBMS continua lá, as tabelas continuam lá, só tem um adaptador no meio.
O Prevayler tem uma idéia interessante e o JXPath tem uma maneira simples de trafegar em um grafo de objetos, porque não juntar os dois?
Talvez o maior problema é que as maiores empresas que trabalham com bancos não estão muito interessadas nisso não… :roll:
Totalmente Philip!!!Pior é q quanto maior o número de Objetos dependentes, pior fica!Um é sempre inserido dentro de outro, e assim sucessivamente…(Arrrrggghh!)
Adeus independência.É dependência direta do objeto predecessor e pior, ficar chamando o Objeto Raiz nas transactions(imagine apenas uns 5 níveis de objetos raiz para vc ver o saco q fica…)
Mas uma coisa nao tem nada a ver com outra, tem?
Um comando (do Prevayler ou nao) precisa saber achar o objeto.
// em vez de:
system.getWorld().getCountry("Brasil").getState("SP").getCity("Sao Paulo").getProgrammer("dukejeffrie").writeCode();
// pode ter:
system.getProgrammer("Sao Paulo", "dukejeffrie").writeCode();
Eu acredito que o Command Pattern e um dominio rico nao sao excludentes… mas eu ja tive algumas dores de cabeca com o Hibernate pra dizer que tem vezes que a gente precisa ser condescendente… [:(]
[]s!
Não são, mas só se você usar o Command para o que ele foi feito:
ApplicabilityUse the Command pattern when you want to
* parameterize objects by an action to perform, as MenuItem objects did above. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks. * specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address space-independent way, then you can transfer a command object for the request to a different process and fulfill the request there. * support undo. The Command's Execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to Execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling Unexecute and Execute, respectively. * support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and reexecuting them with the Execute operation. * 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.
Pense no Command como um ponteiro de função em C.
A propósito, ótimo texto: Transparent Persistence, Transient and Detached Objects, and DTO’s não muito relacionado, mas bom texto mesmo, pena que ainda incompleto
Shoes
Olá!
Vi uma abordagem muito legal do pattern command no Livro Hibernate In Action, no capítulo 8.
O autor usou o command dentro de um Sessio Bean. Ou seja, o session recebia a requisição e delegava a tarefa para o command. O command por sua vez se limitava em fazer chamadas ao DAO ou chamar métodos no domínio, sem usar o command para fazer programação procedural.
Ele começa com um código dentro do command bastante simples, onde algumas lógicas de negócio estão no command, e aos poucos, no decorrer do capítulo, ele vai mostrando como melhorar seu código e mover as lógicas de negócios para os pojos e principalmente, define o que deve ficar no pojo, e o que deve ficar no DAO!
O que achei mais interessante de se utilizar o command é que vc pode testar a operação que ele executa sem depender de qualquer conteiner que seja, já que o command é um objeto java simples. Assim, fica mais fácil de testar a operação e ainda por cima é mais fácil de reaproveitar.
Abraços!
Thiago
Você não repcisa de um Command para isso, basta colcoar a lógica em POJOs
O que achei mais interessante de se utilizar o command é que vc pode testar a operação que ele executa sem depender de qualquer conteiner que seja, já que o command é um objeto java simples. Assim, fica mais fácil de testar a operação e ainda por cima é mais fácil de reaproveitar.Você não repcisa de um Command para isso, basta colcoar a lógica em POJOs ;)
Pois é, se você reaproveita um command, pode ser porque ele tá fazendo “trabalho” demais 
O que achei mais interessante de se utilizar o command é que vc pode testar a operação que ele executa sem depender de qualquer conteiner que seja, já que o command é um objeto java simples. Assim, fica mais fácil de testar a operação e ainda por cima é mais fácil de reaproveitar.Você não repcisa de um Command para isso, basta colcoar a lógica em POJOs ;)
Bom…
Mas onde ficam minhas chamadas ao DAO? Dentro dos POJOS??
Abraços!
Thiago
O que achei mais interessante de se utilizar o command é que vc pode testar a operação que ele executa sem depender de qualquer conteiner que seja, já que o command é um objeto java simples. Assim, fica mais fácil de testar a operação e ainda por cima é mais fácil de reaproveitar.Você não repcisa de um Command para isso, basta colcoar a lógica em POJOs ;)
Pois é, se você reaproveita um command, pode ser porque ele tá fazendo “trabalho” demais
Olá!
bom… não exatamente…
Não disse isso no sentido de você reaproveitar para ser chamada por outros métodos… mas no sentido de que o mesmo command possa ser usando em controler diferentes. Por exemplo, vc poderia usar este command dentro de uma aplicação swing, web e sessions beans! É neste sentido de reusabilidade que me referi!
Abraços!
Thiago
Mas veja só, se o seu command só faz “juntar” os dados de uma interface e passar eles pra os objetos responsáveis pela lógica de negócio, seria complicado reutilizar eles em programas que tivessem interfaces diferentes, como uma aplicação Swing e uma aplicação web.
Eu não vejo como reutilizar commands desse modo.
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.
Bom... Mas onde ficam minhas chamadas ao DAO? Dentro dos POJOS??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.
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
Você não repcisa de um Command para isso, basta colcoar a lógica em POJOs
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!!
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);
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!
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
Opa! Peraí!Objetos do domínio fazendo acesso ao banco de dados? Oh, não!
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.
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…
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
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
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?
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
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… 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!
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!
Desde já agradeço!
Thiago
F
Dae Thiago,
Pq nao da uma olhadinha no JForms?
]['s
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
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:
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!!
Abracos!
“Brevity is the soul of wit”. Acho que eu devia mudar minha sig.
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
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
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.
Oloco meu! :shock:
Posta um exemplo ai!!!
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:
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
Sei lá, o caso não é usar ou não patterns, é não procurar meter patterns onde eles não foram chamados
Colocar toda a coleção do “Padrões de Projeto” ou da coleção do Martin Fowler, não vai resolver o problema, é só ver o que o mestre Jedi Gamma falou:
http://www.artima.com/lejava/articles/gammadp.html
Sobre as transações, a parada seria mais ou menos o seguinte, imagine que você tem que, antes de confirmar uma venda, garantir que o cartão do cliente é válido, a transação da venda só pode ser concluída quando você obtiver a resposta da prestadora dizendo que está tudo “livre”.
O que você faz? Diz pro cliente que a compra está aguardando confirmação e deixa alguém esperando pela mensagem (olha o JMS aqui ó), quando a mensagem chegar, você vê se tá liberado ou não e “termina” a transação. Isso é um caso onde a transação não está no banco de dados. Mas como o Phillip disse, se a transação é só no banco, ela deveria estar dentro dos seus DAOs, não precisa se extender não.
Desse modo, como não cair no anti-pattern “transaction (session) per operation” ?
Olá
Você pdoe manter a transação aberta se seu DAO possuir informação de estado. A questão é que não há porque essa transação deixar a camada de persistência.
Desse modo, como não cair no anti-pattern “transaction (session) per operation” ?
Olha, se você tá numa aplicação web, guarda a sessão e a transação em uma thread local e fecha com um filtro no fim do serviço, se você tá numa aplicação desktop usa aspectos pra pegar o fim de um método de serviço qualquer e fecha a sessão e a transação (também em uma tread local).
E qual o problema de se ter “transaction per operation” quando você está usando um pool de conexões? Elas não vão ser abertas e fechadas a todo o instante, eu acredito que o impacto seja mínimo dentro do sistema.
Outra coisa Phillip, como é que dá pra controlar isso usando estados no Dao, eu chamo um método qualquer pra “fechar” tudo no dao quando terminar?
Criado 29 de maio de 2005
Ultima resposta 5 de jul. de 2005
Respostas 48
Participantes 10
Alura Git Flow: entenda o que é, como e quando utilizar Entenda o que é Git Flow, como funciona seu fluxo com branches como Master, Develop, Feature, Release e Hotfix, além de vantagens e desvantagens.
Lumina Lumina: a IA que te traz resultados Prompts prontos por especialistas. Resolva seus problemas de verdade.
Fiap Graduacao em Tecnologia — FIAP Analise e Desenvolvimento de Sistemas, Engenharia de Software e mais