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!
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.
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 
[quote=pcalcado][quote=douglasfs]
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.
[/quote]
Ou deixar o design procedural de lado e usar um Domain Model ;)[/quote]
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 ?
[quote=douglasfs]
Mas no geral, vc acredita que essa arquitetura é válida como ponto inicial ?[/quote]
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:
[quote=Ironlynx]
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: [/quote]
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.
[quote=pcalcado]
Cada vez mais eu acredito que persistência transparente em java só o dia que que a JVM for projetada para isso.[/quote]
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: [quote=GoF]
Applicability
Use 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.
[/quote]
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
[quote=pcalcado][quote=Thiago Senna]
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.
[/quote]
Você não repcisa de um Command para isso, basta colcoar a lógica em POJOs ;)[/quote]
Pois é, se você reaproveita um command, pode ser porque ele tá fazendo “trabalho” demais 
[quote=pcalcado][quote=Thiago Senna]
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.
[/quote]
Você não repcisa de um Command para isso, basta colcoar a lógica em POJOs ;)[/quote]
Bom…
Mas onde ficam minhas chamadas ao DAO? Dentro dos POJOS??
Abraços!
Thiago
[quote=Maurício Linhares][quote=pcalcado][quote=Thiago Senna]
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.
[/quote]
Você não repcisa de um Command para isso, basta colcoar a lógica em POJOs ;)[/quote]
Pois é, se você reaproveita um command, pode ser porque ele tá fazendo “trabalho” demais [/quote]
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.