Estava aqui pensando em desenvolver um projeto com intuito de aprendizado. O Objetivo é desenvolver um sistema onde minhas regras de negócios ficariam em um servidor rodando um AS (até aqui sem problemas). A Interface com o usuário que seria o ponto chave. Eu teria tanto uma interface Web como Desktop (Swing ou SWT, sei lá) e utilizando as mesmas classes de regras de negócios, será que é possível fazer isso?
Desenvolver apenas para Desktop tranquilo, e desenvolver apenas para WEB é tranquilo, mas gostaria de fazer os 2 com apenas 1 classe de negócios. A dúvida é se isso é possivel e quais frameworks eu devo estudar? Estava mexendo com o Webwork apenas para WEB e estou achando bastante interessante, mas ele é apenas para WEB. Pensei no Spring, mas nunca mexi com o Spring e não sei se da pra fazer essas coisas com ele, além do Webwork poder ser integrado com ele (não sei se funciona legal).
Como eu disse, é apenas para aprendizado. Qualquer idéia, ajuda será bem vinda
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…
[quote=“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: !!![/quote]
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).
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… ).
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[/quote]
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
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.
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.
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.
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.[/quote]
Muito interessante Smota, acho que arrumei algo para estudar nas férias da faculdade :lol:
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.
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… [/quote]
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:
Começa pensando que vc só vai fazer a interface em Swing.
Invariavelmente vc vai acabar desenvolvendo MVC, e alguns padões vêm bem a calhar: DAO, por exemplo, e o padrão Command.
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.
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.
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.
Rico usa o que há de mais avançado e compra as melhores máquinas que existem para compensar.