Swing para Servidor Tomcat, está correto assim??

Muito boa a discução....

Sobre, gostaria do seu parecer sobre qual método usar para a ligação, no sentido que de um lado eu tenho um objeto Cliente, por ex, e no servidor tenho que ter este tal objeto e gravar no banco de dados.... bem como para Fornecedor, Funcionario, Venda, Produto, Comissao, etc.. no mesmo código. Ou seja nao posso denifir um padrão de colunas, pois cada um tem quantidades diferentes de dados.

Você tinha falado sobre XML e CSV...... pesquisei sobre os dois e achei o CSV mais agradável...... qual seria seu palpite? Pelo menos CVS saí o padrão Java, o que seria legal para "desacoplar mesmo" as coisas nao?

jopss

This message was edited 1 time. Last update was at 28/03/2008 15:21:03

Olá

Se você for passar mensagens sem serializar classes, crie suas classes de separadas no cliente e no servidor de modo que as classe no cliente sejam as ideiais para apresentar e no servidor as ideais para persistir.

Se enviar serializado, crie métodos usando reflection que serialize/deserialize de forma genérica. Você terá que replicar no servidor as classes do cliente e pode ser que ainda tenha que usar outras classes para fazer a persistência e construir as respostas das consultas.

Estas respostas só podem ser dadas analisando o sistema de perto e verificando o que é mais fácil de fazer de acordo com os conhecimentos técnicos da equipe. De acordo com o grau de conhecimentos da equipe, a solução adotada pelo Matheus pode ter preferência. A gente nunca deve esquecer de que a melhor solução é a que funciona e que o ótimo é inimigo do bom.

[]s
Luca

This message was edited 2 times. Last update was at 28/03/2008 16:04:07

Luca wrote:Se você for passar mensagens sem serializar classes, crie suas classes de separadas no cliente e no servidor de modo que as classe no cliente sejam as ideiais para apresentar e no servidor as ideais para persistir.

Perfeito. Nesse caso seriam dois sistemas completamente independentes, com classes independentes, trocando mensagens por algum protocolo específico - XML, CSV, JSON, etc. O responsável por manter o protocolo seria o servidor e, para acessar seus serviços, basta seguir o protocolo. Qualquer alteração na aplicação servidora, desde que não altere esse protocolo, não causa impacto algum no cliente.

Luca wrote:Se enviar serializado, crie métodos usando reflection que serialize/deserialize de forma genérica. Você terá que replicar no servidor as classes do cliente e pode ser que ainda tenha que usar outras classes para fazer a persistência e construir as respostas das consultas.

Agora, neste caso, mesmo não havendo RPC, depender das mesmas classes tanto no cliente quanto no servidor não acaba deixando o sistema tão acoplado quanto? O ponto é qualquer alteração nas classes do servidor afeta diretamente o cliente - não necessariamente nessa mesma ordem

. E acho que é exatamente isso que você sugeriu evitar, certo?

Ter as mesmas classes no cliente e servidor, apenas usando servlets e serialização via XML, etc, ao invés de um proxy fazendo as chamadas aos métodos remotos, ainda deixa os dois sistemas acoplados. A conclusão que chego é que o ideal seria usar a primeira alternativa, onde não há dependência entre o cliente e servidor.

Luca wrote:De acordo com o grau de conhecimentos da equipe, a solução adotada pelo Matheus pode ter preferência.

Na verdade, quando iniciamos esse projeto eu sugeri uma arquitetura REST. Mas como já havia um projeto feito em uma arquitetura muito semelhante, optamos por usá-la. Também acredito que não seja a melhor escolha, mas neste caso, fui voto vencido.

This message was edited 1 time. Last update was at 28/03/2008 16:08:57

A conclusão que chego é que o ideal seria usar a primeira alternativa...

É dois... estou vendo sobre CSV.. a ideia seria criar um arq com os dados e cabeçalho e mandar pro server... lah ele abre e faz o objeto.. seria isso??

jopss

Olá

Matheus Tardivo wrote: mesmo não havendo RPC, depender das mesmas classes tanto no cliente quanto no servidor não acaba deixando o sistema tão acoplado quanto? O ponto é qualquer alteração nas classes do servidor afeta diretamente o cliente - não necessariamente nessa mesma ordem . E acho que é exatamente isso que você sugeriu evitar, certo?

Certo. Na verdade seria ao contrário o mais provável de acontecer: alteração no cliente implica em alteração no servidor. Nos dias de hoje, fraco acomplamento deve ser um objetivo e tudo que dificultar deve ser pesado, medido, avaliado e só adotado se não houver outra solução igualmente fácil de fazer.

Matheus Tardivo wrote: Na verdade, quando iniciamos esse projeto eu sugeri uma arquitetura REST. Mas como já havia um projeto feito em uma arquitetura muito semelhante, optamos por usá-la.

Fiz questão de lembrar desta possibilidade por que às vezes a gente critica determinada arquitetura sem saber exatamente o motivo pelo qual ela foi adotada. Por tudo que a gente fala hoje em dia de desenvolvimento ágil, de priorizar coisas que o cliente pode usar logo, de evitar desperdícios (Lean), etc. e tal, não adianta a gente ficar buscando algo que a equipe não domina e corre riscos demasiados. Apesar de REST ser algo bem mais promissor, neste caso a opção adotada parece ter sido a melhor possível.

[]s
Luca

Luca wrote:Este papo só está acontecendo porque o Genesis induz o usuário a adotar esta arquitetura engrunvinhada, acoplada, pesada, enxuriçada, etc. e tal que para mim não faz sentido. Já comentei isto com o Michael e ele respondeu que esta não é a única arquitetura do Genesis e que só usa quem quer. Para mim seria melhor que o Genesis não admitisse esta arquitetura com EJBs/RMI/etc. no cliente.

Só uma observação quanto a isso: usamos o Genesis apenas para binding e outras pequenas coisas no cliente. Neste caso, não usamos o esquema de chamadas remotas do Genesis - tanto que implementamos algo diferente usando o Spring. Aliás, como falei na resposta anterior, já havia um outro projeto usando uma arquitetura parecida, por isso não podemos nem falar que o Genesis nos influenciou a usar RPC.

Nada que acrescente muito a discussão, mas gostaria de deixar claro esse ponto.

Opa..

Gostaria de discutir sobre a quantidade de lógica existente na aplicacao cliente.

No meu caso, eu estou fazendo assim:

NO CLIENTE.
Os dados da tela (swing) vai parar em um objeto bean.... faço as validações nestes objetos, e replico na tela para ser mais efetivo..... então este objeto bean é convertido em XML, e send pela rede!

NO SERVER.
Um servlet recebe o xml, reconverte em objeto bean (este anotado para hibernate) e efetua a gravação no banco de dados, retornando o necessário.

------------
Mas me parece estranho. O cliente parece mais enxuto do que o necessário e não possui muita lógica no server, somente receber e gravar no banco. Por outro lado, nao tem muito mais o que fazer, só se eu colocasse as validações lá no server ao inves no cliente, mas ao meu ver isso geraria maior tráfego na rede.
Está correto isso? O que seria uma forma ideal?

jopss

Olá

jopss wrote:...só se eu colocasse as validações lá no server

Como venho insistindo desde o início, é sempre preciso fazer as validações também no servidor por motivos de segurança (prevenir contra cliente fake)

[]s
Luca

This message was edited 2 times. Last update was at 11/04/2008 16:00:30

... ae seria validação no bean cliente, no server e na tela ??!!

no caso eu estou duplicando as classes bean no cliente e server para efetuar da forma que falei..... eh "estranho" isso?

teria mais oq para colocar no server? Nao vejo oq mais.....

por favor, tbm precisaria de um coment qualquer neste post:
http://www.guj.com.br/posts/list/86894.java#464781

vlw novamente!

jopss

Olá

jopss wrote:... ae seria validação no bean cliente, no server e na tela ??!!

Pouco importa se você vai usar Bean, Clipper ou assembler, tem que validar TAMBÉMno servidor.

Atente que na mensagem anterior coloquei também em negrito.

[]s
Luca

Notícias, artigos e o maior fórum brasileiro sobre Java