Idéia para um Projeto "completo"

E aí manchester, não sei se seria possível utilizar estes frameworks, mas já vi alguns projetos onde o acesso do Desktop é feito através de HTTPConnection direto a um servlet, dessa maneira as duas interfaces podem utilizar o mesmo ponto de entrada no server…

Talvez alguém já tenha usado essa abordagem aqui no GUJ. No próprio Petshop da Sun a parte desktop utiliza HTTPConnection para se comunicar com o servidor…

Acho q não ajudei muito, né :lol: !!!

“TedLoprao”:

E aí manchester, não sei se seria possível utilizar estes frameworks, mas já vi alguns projetos onde o acesso do Desktop é feito através de HTTPConnection direto a um servlet, dessa maneira as duas interfaces podem utilizar o mesmo ponto de entrada no server…

Talvez alguém já tenha usado essa abordagem aqui no GUJ. No próprio Petshop da Sun a parte desktop utiliza HTTPConnection para se comunicar com o servidor…

Acho q não ajudei muito, né :lol: !!!

eu até conheço o HttpConnection, mas como você disse, eu terei que ligá-lo diretamente a um servlet, ae eu não consigo utilizar algum framework para facilitar o trabalho (principalmente na WEB).

Mas valeu pela ajuda Ted

MVC padrao.

Voce separa a parte comum a ambos, e a unica coisa que voce refaz eh a view. Voce pode usar algum container sem problema algum tambem, como Spring ou Pico. O unido “detalhe” eh que voce nao deve chamar algum metodo “comum” a ambas views de uma maneira acoplhada demais ( ou seja, nao chamar queries sql diretamente de dentro dos listeners do swing, por exemplo, mas sim delegar para alguma classe adaptadora / requisitar a algum Factory etc… ).

Rafael

“Rafael Steil”:

MVC padrao.

Voce separa a parte comum a ambos, e a unica coisa que voce refaz eh a view. Voce pode usar algum container sem problema algum tambem, como Spring ou Pico. O unido “detalhe” eh que voce nao deve chamar algum metodo “comum” a ambas views de uma maneira acoplhada demais ( ou seja, nao chamar queries sql diretamente de dentro dos listeners do swing, por exemplo, mas sim delegar para alguma classe adaptadora / requisitar a algum Factory etc… ).

Rafael

Acho que minha visão está meio “fechada” ainda. O que eu pensei mais ou menos era por exemplo usar o WW para WEB. Dentro deles chamar as Actions e cada Action possui sua classe. Nessas classes teriam minhas regras de negócios e poderiam ser utilizadas quando for utilizado com uma interface Swing. Gostaria de usar o WW por exemplo, pois ele já implementa algumas coisas na WEB que é um saco fazer na mão, como por exemplo validação de campo, uso de interceptors e etc.
O que eu poderia no caso do Swing, era fazer um “mini” controlador, que irá pegar as requisições do Swing, preparar as informações e chamar essa s Classes (as mesmas que o WW usa). Seria mais ou menos implementar o que o WebWork faz, mas em uma versão Swing certo?
Como eu disse, estou com uma visão “fechada” para achar uma solução mais elegante para esse caso.

Voce pode continuar usando ww pra web, sem problemas. Mas as tuas actions seriam apenas “laranjas”. A ideia eh que a regra de negocios nao deva saber o ambiente onde esta rodando.

Por exemplo, a classe “Produto” deve ter coisas somente de algum produto, como nome e preco. Nao deve ter referencia para um JButton ou HttpSession.

A classe para salvar produto tambem nao deve ter nada dependente. Voce pode usar hibernate ou jdbc no braco, desde que nao acoplhe a alguma view… por exeplo, vc faz a classe para salvar o produto de maneira que apenas receba o objeto produto a salvar… algo como

public class ProdutoPersistence {
    public void save(Produto p) {
        // Aqui dentro vc simplesmente cria o statamente
        // e da um execute nele
    }

    public List selecionaProdutos() {
        // aqui voce consulta o banco de dados, 
        // popula os objetos Produto, joga no list
        // e retorna a lista. nada alem disso
    }
}

entao, na tua action, para salvar algum produto, vc faz

...
Produto p = .... // cria produto
ProdutoPersistence ps = .... // cria persistencia
ps.save(p);
...

ProdutoPersistence ps = .../
List todosProdutos = ps.selectProdutos();

e entao vc faz a parte especifica da view em questao, como setar o contexto do Velocity ou popular o JList.

A view tem que delegar as responsabilidades comuns a uma entidade “neutra”.
Nao ha, para swing, uma qtde de frameworks no estilo ww como existem para ambiente Web, muito pq sao ambientes bastante diferentes.

Rafael

A Parte de separar as coisas eu entendi bem, alias, não será tão simples como eu pensei, pois por exemplo se eu for preencher um JList será em um local diferente do que preencher um Combobox.

Vou começar implementar algumas coisas aqui, começando inicialmente montando a parte web com o WW, e depois tentar criar uma parte Swing.

Agora outra pergunta. Se eu quiser utilizar uma Interface em Delphi ou C++ por exemplo (pois é mais leve que Swing e SWT). O processo será bem diferente certo? ae já terei que fazer troca de mensagens através de sockets invés de usar HttpConnection, certo?

Bom, diferenca ha as obvias, uma vez que a forma como vc trabalhar com um <select> eh bem diferente de um JList. Mas, uma vez que vc tem uma lista com os objetos, o resto eh soh trabalho de popular os componentes da tela.

Rafael

Entrando de gaiato …

Na verdade você refaz a view e o controller mesmo trabalhando com MVC.

Como o controller é quem sabe manipular a sua view E sua camada de negócios (é a ponte) ele deve ser reescrito.

No caso se você quer ficar com o Webwork seu trabalho será polpado. Ele se baseia na integração com o Xwork que é uma implementação genérica (e bem feita diga-se de passagem) do Command Pattern.

As actions então serão uma só tanto no cliente Web quanto no desktop … vc precisa soh escrever o controller que no fim das contas será mais simples do que se vc nao usar o Xwork.

Nesse meio de campo vc pode integrar com o Pico tb pra ter um container IoC mais parrudo … e por ai vai.

“smota”:

Entrando de gaiato …

Na verdade você refaz a view e o controller mesmo trabalhando com MVC.

Como o controller é quem sabe manipular a sua view E sua camada de negócios (é a ponte) ele deve ser reescrito.

No caso se você quer ficar com o Webwork seu trabalho será polpado. Ele se baseia na integração com o Xwork que é uma implementação genérica (e bem feita diga-se de passagem) do Command Pattern.

As actions então serão uma só tanto no cliente Web quanto no desktop … vc precisa soh escrever o controller que no fim das contas será mais simples do que se vc nao usar o Xwork.

Nesse meio de campo vc pode integrar com o Pico tb pra ter um container IoC mais parrudo … e por ai vai.

Muito interessante Smota, acho que arrumei algo para estudar nas férias da faculdade :lol:

Mais um de Gaiato.

Que tal 4 camadas?

Você poderia deixar as regras de negócio em Web services. Ficaria bem distinto o que é visão (Swing, Velocity, etc.), o tratamento das solicitações (WW, etc.) , a execução das solicitações (nos Web Services) e o modelo.

E assim permitiria usar Delphi ou C++ tb…

hummm … web services tudo? sei nao, a performance seria meio fraquinha … web services eh legal pra disponibilizar alguns servicos da sua api, nao tudo

“vamorim”:

Mais um de Gaiato.

Que tal 4 camadas?

Você poderia deixar as regras de negócio em Web services. Ficaria bem distinto o que é visão (Swing, Velocity, etc.), o tratamento das solicitações (WW, etc.) , a execução das solicitações (nos Web Services) e o modelo.

E assim permitiria usar Delphi ou C++ tb…

Interessante a idéia, eu não tinha pensando em usar Web Services em tudo, mas como o Samuel Mota disse, a performance de WebServices não é muito boa, e se for usar no sistema inteiro, todas as partes irão ficar fraquinhas.
Estou com algumas idéias em mente para iniciar, e claro, qualquer ajuda/opinião será bem vinda :lol:

Bom, eu acho que posso dar umas dicas.

1. Começa pensando que vc só vai fazer a interface em Swing.

2. Invariavelmente vc vai acabar desenvolvendo MVC, e alguns padões vêm bem a calhar: DAO, por exemplo, e o padrão Command.

3. Se vc usar o padrão command direitinho, vc pode construir fachadas pra criar esses comandos, e essas fachadas podem ser objetos remotos que vc acessa por RMI.

4. Seus servlets (porque não webwork?) podem usar as mesmas fachadas e os mesmos comandos. A lista de objetos que vc puxa da fachada pode ir pro contexto do velocity, ou preencher o modelo na app Swing.

5. Vc pode ter sua app rodando num processo separado, e tanto os clientes em Swing como os servlets (ou actions do webwork) acessam remotamente. Vc tem uma app 3-tier!!

Fui simplista de propósito, pro post não ficar muito grande, e tem vários detalhes que eu nem parei pra pensar. Mas já fiz uma coisa assim e compensa muito. Mas vc tem que saber manejar o tempo legal.

[]s

“dukejeffrie”:

Mas já fiz uma coisa assim e compensa muito. Mas vc tem que saber manejar o tempo legal.

[]s

Essa é a idéia . Como não é um projeto real, eu quero através desse, aprender para no futuro quem sabe, aplicar em um projeto real.

Preocupação com performace é coisa prá pobre. Rico usa o que há de mais avançado e compra as melhores máquinas que existem para compensar.

Falando sério, isso vai depender da sua aplicação. Para muitos casos isso não chega a ser problema.

Dukejeffrie, por que começar pensando que a aplicação vai ser só Swing? Na Web não é muito mais claro a distinção entre as camadas?