onde abrir a transação e onde fazer o commit.

Luca wrote:A partir desta lembrança repito: não é complexo. Mas é claro que não basta ser certificado Java para saber como.

Tem certas coisas que o que limita é a tecnologia atual. Quando o cliente é desconectado você precisa tomar alguns cuidados a mais. Seria ótimo se você conseguisse obter as instâncias de entities no cliente Swing e as usasse livremente sem se importar com a transação, mas infelizmente isso ainda não é a realidade.

Algumas vezes você precisa usar um Stateful para driblar um LazyLoad, ou fazer uma interface remota que limite o que o cliente pode fazer no Swing, ou forçar um FetchType.EAGER. Resumo: Essa abstração de um objeto remoto ainda é falha, principalmente no controle transacional de operações remotas.

Olá

Rodrigo, o que é preciso é se livrar deste ranço de RPC, RMI e sistemas síncronos. Habitue-se a desenvolver trocando mensagens entre o servidor e a camada de apresentação e deixe tudo isto que falou no servidor. Use arquitetura de mensagens para garantir ao cliente a atomicidade das transações.

E para falar em futuro, para mim ele será assíncrono. Todo o legado que for baseado em RPC (ou pior ainda, em RMI) ficará prejudicado. Já que você tem escola, porque não aprender e ensinar logo como fazer direito? Estamos usando Java que permite tudo isto com facilidade. É só questão de aprender a usar Java com todo seu potencial.

Se você gosta de padrões, leia Gregor Hohpe.

[]s
Luca

Luca wrote:

No modelo que uso entre o Swing e o resto, há troca de mensagens usando arquitetura de mensagens HTTP e deixando a camada de apresentação o mais desacoplada possível.

Fiz sempre assim mesmo que o sistema rode todo no mesmo micro. O negócio é fazer uma vez para perceber que é fácil.

Só não me convidem para elogiar projeto que acessa EJBs no Swing a menos que me provem tim tim por tim o porque desta escolha. Até hoje vi poucos que justificassem corrretamente esta opção.

Camada de Apresentação "o mais desacoplada possível" é um custo alto. É bonito, mas também precisa justificar esse custo. Concorda? Outra coisa, concorda que trafegar XML com cópia dos dados dos objetos não seria a mesma coisa que usar DTOs?

Meu projeto acessa EJB direto no Swing de maneira simples, mas é EJB 3, onde os entities são livres para ir para o cliente, mas tem as limitações que já postei aqui... Agora, a produtividade é muito alta. Fazemos telinhas em minutos...

Olá

Nem vou me ater a nomenclatura DTO que geralmente é usada em outro contexto. Todos os sistemas Swing que tenho participado, de uma forma ou de outra, enviam mensagens XML para o servidor. O uso de XML é apenas para facilitar a depuração da mensagens. Nem sempre elas representam objetos serializados.

Uma opção bem rápida de desenvolver um sistema assim é usar XML-RPC. Mas aí cai naquele tal de RPC que eu estou tentando me livrar. O ideal é usar mensagens assíncronas e se valer de técnicas de mensagens para garantir a atomicidade.

Depois que se sabe como fazer, o resto é tão simples ou mais do que o modo como faz. Em um dos sistemas em que eu trabalhei, que atendia a transações de cartão de crédito, o servidor era minúsculo pois TODAS as transações eram tratadas da mesma forma através do uso de reflection. A gente quando precisava criar uma nova transação o servidor já estava pronto. Neste caso, quando falo em servidor é apenas o carinha que recebe o HTTP dos clientes e repassa para o back end de acordo como este entende.

Depois que a gente se acostuma a trabalhar deste jeito, já tem tudo pronto para reusar em outros projetos.

[]s
Luca

Luca wrote:

Depois que a gente se acostuma a trabalhar deste jeito, já tem tudo pronto para reusar em outros projetos.

[]s
Luca

Estou fazendo mais um Pet Project na ASPERCOM nos moldes do Hotmotors. É parte do meu próximo artigo. Estou fazendo em Swing e EJB 3, se você quiser podemos fazer também na sua abordagem para podermos ver as diferenças...

De qualquer forma, ainda acredito que seria melhor que no futuro pudéssemos manusear os entities na camada de apresentação sem limitações, navegando livremente nas associações, chamando operações de negócio e com uma performance excelente...

Outro ponto: acho um pouco "utopia" uma camada de apresentação totalmente desacoplada. Mudanças no domínio quase sempre forçam uma mudança na camada de apresentação, sempre tem um campo novo que entrou, ou uma associação que teve multiplicidade alterada. Por mais que a apresentação esteja desacoplada, ela vai ter alterações motivadas pelo domínio...

Olá

rodrigoy wrote: acho um pouco "utopia" uma camada de apresentação totalmente desacoplada.

Concordo plemamente. As vezes, basta trocar o servidor para quebrar o acoplamento. Este é o motivo porque eu sempre digo: acoplamento mais fraco possível ao invés de fraco acoplamento ou desacoplamento total.

São 2 as frases chaves que todo desenvolvedor tem que ter na cabeça sempre:
"Coesão mais forte possível" e "acoplamento mais fraco possível"

O problema do uso dos EJBs no cliente é que quebra o acoplamento cedo demais. É claro que tem vantagens na velocidade de desenvolvimento. No dia em que o genesis rodar com EJB3 vai ficar moleza desenvolver um sistema assim. Mas eu ainda acho que seria sacrificar a qualidade da arquitetura em benefício da facilidade do desenvolvimento. Isto só poderia ser considerado bom se o cliente só pagasse pela arquitetura mais acoplada.

[]s
Luca

eita, a discussão tá boa d+!

Acho que também fui mal entendido em algum momento aí para trás.
Não discordei do que vocês estão debatendo.

Rodrigo, não critiquei o OpenSessionInView. Pelo contrário, eu acho que é a melhor opção para um sistema web sobre http. E eu acho que se aplica bem ao seu sistema desacoplado baseado na troca de mensagens também Luca.

A discussão inicial era se o melhor é abrir uma sessão com o bd na hora que chega a requisição a ser tratada e deixa ela aberta até o momento em que a requisição acabou de ser tratada; ou se é melhor ter uma Fachada de métodos de negócio e controlar o ciclo de vida da sessão dentro da camada de negócios.

O grande problema de deixar a sessão restrita dentro da camada de negócios (eu nem gosto de fachadas procedurais, mas isso é outro assunto) é que a camada de negócios tem que retornar exatamente/somente aquilo que o sistema precisa para montar a resposta da requisição. O que inclui saber quais relacionamentos vão ser navegados para iniciá-los antes e não tomar LazyInitializationException, ou ainda mandar só o que vai ser usado através de uma estrutura-pseudo-orientada-a-objetos (DTO/VO). Saber o que você vai precisar usar mais para frente às vezes requer prever o futuro, e é disso que não gosto.

Mantendo a sessão aberta até o término do tratamento da requisição, não há a necessidade de se preocupar com isso. Eliminando grande parte da complexidade! A camada de negócio retorna algum(s) objeto(s) do seu domínio suficiente(s) para renderizar a view e você navega em relacionamentos a vontade.

E é aí que vem grande parte da confusão do tópico. Renderizar a view hoje, pode tanto ser criar um html para ser renderizado pelo browser, quanto montar um xml/json/texto para ser enviado como resposta ou mensagem assíncrona ao cliente remoto. O conceito de view que nós tinhamos até hoje já é @Deprecated. Eu estou hoje num projeto em que "renderizar a view" significa gerar um xml para ser digerido por Flash!

O que o Luca diz faz muito sentido. Não há motivos para não desacoplar a view nesse mundo da internet. Só que as views já são desacopladas, sejam elas um browser ou o seu eclipse.

ps.: é claro que eu só repeti tudo que estava escrito aí pra cima, do meu jeito!

Olá

Fábio, é exatamente esta a mentalidade.

É claro que se o cliente quiser lixo e só pagar por lixo, não há porque não lhe entregar lixo.

Mas se a gente puder fazer um tiquinho melhor também não é difícil. Já participei de um projeto com camada de apresentação feita em Swing em que havia uma outra interface via Struts

A equipe que desenvolveu o Struts não manjava nada de Swing e fizeram a parte deles como sabiam. Era uma coisa pequena a parte do Struts mas mostrou como foi bom fazer as coisas todas no servidor deixando o cliente Swing só como camada de apresentação e um mínimo de validação (repetida também no servidor por questões de segurança)

[]s
Luca

Aproveitando a discussão se eu tenho uma aplicação onde a seguinte estrutura é utilizada: view - bd - dao....
Porque eu não poderia controlar a transação no DAO, "já li aqui no forum que se eu controla-se no DAO iria ser complicado se eu fosse utilizar mais de um DAO, deram um exemplo aqui mesmo, salvar um pedido e depois os itens".
porque ???? alguém poderia me explicar por favor ?

[]'s

JavaTeenager Membro desde: 30/03/2006 16:51:25 Mensagens: 197 Offline

porque se você controla a transação no DAO, você salva um pedido, e depois dá erro ao salvar um item, você não tem como dar o rollback no pedido
Assim você não garante a atomicidade

Luca wrote:No modelo que uso entre o Swing e o resto, há troca de mensagens usando arquitetura de mensagens HTTP e deixando a camada de apresentação o mais desacoplada possível.

Luca, poderia dar mais detalhes da arquitetura que vc esta acostumado a usar/fazer em suas aplicações swing?

Uma outra coisa, existe a possibilidade da minha aplicação ter views web e JME, no caso das view Swing e JME, elas podem ser "desconectadas" fazendo sincronia posterior dos dados, vcs recomendam dividir isso em "módulos" separados, com um core, e um módulo para cada cenário específico? qual a melhor maneira para se fazer/integrar isso?

Não sei se deu pra entender, mas vamos lá hehe

Luiz, o problema de um sistema Desktop seja em Swing ou qualquer coisa é saber isolar legal os componentes não só para reutilizá-los mas também para manter uma boa coesão.

Para deixar componentes isolados nós usamos muito listeners (AKA Observers). Se você lembra do curso, existem mensagens call e signal.

Me manda um mail que um dia podemos até marcar para você ver o meu projeto atual...

Falow...

Luca, como você faz para montar e desmontar mensagens XML-RPC. A idéia parece boa...

Você usa algum framework? Tem exemplos?

Rodrigo Y.

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