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

Também concordo que deva ser na sua camada de negócios.

Acho que isso varia de sistema em sistema, dependendo de sua arquitetura. Se a sua aplicação tem uma fachada para isolar a camada de negócio do controle, acho que o controle da transação deve ficar na fachada.

Há casos onde o próprio controle (servlet por exemplo) tem acesso direto aos DAO’s para persistir os objetos. Nestes casos, em minha opinião, o controle da transação fica no controle. Você poderia por exemplo criar um filtro para ajudá-lo.

Thiago Senna:

Acho que isso varia de sistema em sistema, dependendo de sua arquitetura. Se a sua aplicação tem uma fachada para isolar a camada de negócio do controle, acho que o controle da transação deve ficar na fachada.

Há casos onde o próprio controle (servlet por exemplo) tem acesso direto aos DAO’s para persistir os objetos. Nestes casos, em minha opinião, o controle da transação fica no controle. Você poderia por exemplo criar um filtro para ajudá-lo.

Acredito ter sido BEM CLARO em relação ao problema. O que você disse acima já sabemos!
A dúvida é sobre a arquitetura descrita na primeira mensagem.

Obrigado luiz pela sua opinião.

Amigo acho que a transação deve estar na regra de negocio, imagine q vc tem uma regra que faz o seguinte grava um pedido depois os itens, vc vai usar o dao de pedido e dao de itens, entao vc abre a transacao e executa os dois daos, caso 1 de errado ele desconsidera toda transações…
bom nao sou o dono da verdade…

[]'s

chicocx:

Acredito ter sido BEM CLARO em relação ao problema. O que você disse acima já sabemos!
A dúvida é sobre a arquitetura descrita na primeira mensagem.

Existem visões diferentes sobre camada de ‘negócio’. Você poderia muito bem ter uma camada de negócio sem uma fachada.

Um exemplo seria dentro do seu próprio controle você chamar o método funcionario.save(), ou seu controle chamar fachada.salvarFuncionario(funcionario).

Você pode ter achado que foi bem claro, mas posso entender camada de negócio de várias maneiras, ou seja, IMHO, você não foi tão claro.

Se o seu sistema roda todo em uma única máquina virtual, a melhor solução é colocar o controle transacional na camada de apresentação usando um “pattern” chamado “Open Session in View”.

http://www.hibernate.org/43.html

Tem uma implementação exemplo disso usando Struts no nosso site da Hotmotors (veja a implementação de HibernateRequestProcessor.java):

http://www.aspercom.com.br/hotmotors

Objetos de negócio são cegos com relação à transação.

Eu costumo utilizar interceptors para tratar as transações.

Trabalho a pouco tempo com Java, porém, um projeto que eu participei tinha algo bem parecido com isso…

Nós desenvolvedores decidimos colocar na camada de negocio, por que se a gente colocasse as transações na camada de persistencia ia ser complicado, imagina você querendo salvar uma compra, você teria que abrir uma transação pra salvar a compra e se você precisa-se de chamar outro dao para salvar um pedido ia ser complicado, então colocando na camada de negócio um nível acima nós podemos abrir uma unica transação e persistir os dois de uma vez só, se por um acaso acontece-se um erro ele iria dar um rolback em tudo…

não sei se estou muito correto mas…

se estiver errado me corrija é bom pra trocar experiência…

[]'s

chicocx:

Tenho um projeto com as camadas:

Visao -> controle -> negocio -> persistencia -> banco
e um pojo de trafegando entre elas.

Onde devo gerenciar a transação (tx.begin() e tx.commit):
no controle, no negocio ou na persistencia ?

Acredito que seja na camada de negocio mas o pessoal aqui na empresa insiste que deve ser no controle…

Acho que um problema pode estar aqui tambem " e um pojo de trafegando entre elas", não seria esse o mochileiro das galaxias do shoes?

Não achei uma referncia sobre ele no fragmental mas sei que tem no Artigo sobre Arquitetura de Camadas em Java EE publicado pela revista Mundo Java em Janeiro de 2006 (edição 15).

rodrigoy:

Se o seu sistema roda todo em uma única máquina virtual, a melhor solução é colocar o controle transacional na camada de apresentação usando um “pattern” chamado “Open Session in View”.

http://www.hibernate.org/43.html

Tem uma implementação exemplo disso usando Struts no nosso site da Hotmotors (veja a implementação de HibernateRequestProcessor.java):

http://www.aspercom.com.br/hotmotors

Objetos de negócio são cegos com relação à transação.

Na camada de apresentação mas no controle(MVC) né? Pois eu acho que eu posso trocar minha visão(MVC) sem afetar o controle de transação que esta no controle(MVC)

Rodrigo só uma dúvida! Controlar transações não seria o trabalho de uma “Unidade de Trabralho (Fowler)”?

brunohansen:

Na camada de apresentação mas no controle(MVC) né? Pois eu acho que eu posso trocar minha visão(MVC) sem afetar o controle de transação que esta no controle(MVC)

Rodrigo só uma dúvida! Controlar transações não seria o trabalho de uma “Unidade de Trabralho (Fowler)”?

Por incrível que pareça, o Open Session in View é na View mesmo, no V. Pensando num ambiente WEB, a cada requisição a transação é aberta logo que a requisição inicia e é fechada quando a requisição é renderizada no cliente. Tudo que ocorre dentro desse período é uma unit of work.

Não é difícil fazer isso usando o RequestProcessor do Struts ou a sugestão de usar filtros que o Diogo sugeriu… é a maneira mais simples de fazer num ambiente web, agora se é um cliente desconectado (como aplicação Swing) aí é diferente…

Se você quiser ser purista, o correto seria as transações serem gerenciadas na camada de negócio. Porém trabalhar com a View em Open Session pode ser uma alternativa interessante se você trabalha com o Lazy Loading do Hibernate, visto que isto, em alguns casos, pode te trazer um bom ganho de desempenho. Se não for o caso, a camada de negócios seria, na minha opinião, a escolha mais acertada.

eu diria que o open-session-in-view não está aplicado a nenhuma das camadas MVC, justamente porque engloba todas elas.

Também diria que é a melhor alternativa para o seu caso, pois a responsabilidade de controle transacional está centralizada e os seus objetos de domínio não precisam mais ser responsáveis pelo controle de transações. Código repetido (copy & paste) pelo sistema todo nunca é saudável…

Controlando as transações com filtros/interceptors simplifica bastante, mas existe a restrição de apenas um transação por requisição. O que não é exatamente um problema, porque a grande maioria das aplicações na web só precisam de uma transação por requisição mesmo.

Resolvendo o caso comum (99%) de uma maneira simples, você pode tratar diferente os casos específicos (1%).

Claro que não tenho base científica nenhuma para essas estatísticas: experiência e feeling :D.

chicocx:

Acredito que seja na camada de negocio mas o pessoal aqui na empresa insiste que deve ser no controle…

Olá,

Se voces colocarem na camada de controle e daqui uns tempos pecisarem expor a camada de negocio como servico, seja como Web Services, Rest ou qualquer outro protocolo voces poderao ter um grande problema.

Ja que eles pensam isso, pergunta pra eles como ficaria se isso acontecer, acho que os argumentos deles irao cair drasticamente.

]['s

Isto é verdade!! Se existir a possibilidade da camada de negócios rodar remotamente, esqueça open session e gerencie tudo na camada de negócios de forma encapsulada.

PS: A exposição da camada negócios via Web Service poderia ser feita utilizando um servlet endpoint, mas com certeza não seria a alternativa mais adequada.

Olá,

Pois é, Open In View resolve boa parte dos problemas, mas quando falamos em arquitetura acredito que temos que pensar em muitas possibilidades. Por isso acho que nossa maior ajuda aqui seria somente indicar o que pode ocorrer usando uma ou outra aboradagem.

]['s

Olá

rodrigoy:

Se o seu sistema roda todo em uma única máquina virtual, a melhor solução é colocar o controle transacional na camada de apresentação usando um “pattern” chamado “Open Session in View”.

http://www.hibernate.org/43.html

Tem uma implementação exemplo disso usando Struts no nosso site da Hotmotors (veja a implementação de HibernateRequestProcessor.java):

http://www.aspercom.com.br/hotmotors

Objetos de negócio são cegos com relação à transação.

Rodrigo, gosto muito das suas mensagens mas desta eu discordo.

Quem quer fazer uma aplicação com acesso a banco de dados na camada de apresentação como se fazia no milênio passado, deve usar Clipper, VB ou Delphi. Não usem Java para isto.

[]s
Luca

Luca:

Rodrigo, gosto muito das suas mensagens mas desta eu discordo.

Quem quer fazer uma aplicação com acesso a banco de dados na camada de apresentação como se fazia no milênio passado, deve usar Clipper, VB ou Delphi. Não usem Java para isto.

[]s
Luca

Fala Luca, também gosto das tuas mensagens, mas acho que tu não entendeu o que o pattern OpenSessionInView prega. Não estou falando para colocar comandos SQL nos JSPs, estou falando para colocar a ABERTURA e FECHAMENTO da transação na VIEW de forma a encapsular tudo o que acontece na requisição web numa unit of work…

Agora, estou dizendo no escopo de uma aplicação Java Web usando Struts, JSP ou outro framework web qualquer… Nesse cenário, não consigo ver uma opção que seja melhor que o OpenSessionInView…

Estou trabalhando num projeto Desktop em Swing, e choro muito todas as tardes por não poder abrir a transação no cliente desconectado! Cliente descontectado é mais complexo, tem que pensar nas questões do LazyLoad e objetos desatachados…

Mesmo num ambiente WebServices, continuo achando melhor deixar o controle transacional fora dos objetos de negócio… negócio é negócio, infra-estrutura é infra-estrutura…

Controle de transação é mais uma pedrinha no sapato da evolução dos sistemas OO…

Realmente, clientes desconexos são bem mais complexos. Não adianta pensar em lazy-loading, você precisa saber exatamente o que mandar para o cliente remoto, pois o uso da rede/banda tem que ser otimizado.

Difícil decidir por essa complexidade toda só porque "um dia seu sistema pode ser acessado por uma interface desktop desconexa".

Muitas vezes é bem ruim adicionar muita complexidade tentando prever o futuro!

ps.: boa leitura =&gt https://gettingreal.37signals.com/

Olá

Sua frase sobre uma única máquina virtual que me refiro é esta e este pattern se chama JavaClipperTabajareitor

Separar a camada de apresentação do acesso ao banco de dados não é introduzir complexidade. É apenas fazer um sistema que sirva para alguma coisa.

Repito, se você se satisfaz com um sistema isolado que exige levar seu computador junto consigo, então use Clipper, VB ou Delphi.

Mas para mim nem agenda pessoal eu admito sem acesso à Internet pois quero acessá-la de onde eu estiver no mundo.

[]s
Luca

Olá

Cliente desconectado apenas significa que você não tem os demais componentes do sistema instalados e replicados em sua máquina.

Repito pela quinquamilionésima vez aqui no GUJ: escrever aplicações isoladas em 2006 é o pior erro que um desenvolvedor pode cometer.

[]s
Luca

Fabio Kung:

Realmente, clientes desconexos são bem mais complexos. Não adianta pensar em lazy-loading, você precisa saber exatamente o que mandar para o cliente remoto, pois o uso da rede/banda tem que ser otimizado.

Difícil decidir por essa complexidade toda só porque "um dia seu sistema pode ser acessado por uma interface desktop desconexa".

Muitas vezes é bem ruim adicionar muita complexidade tentando prever o futuro!

ps.: boa leitura =&gt https://gettingreal.37signals.com/

Fala Fabio, atualmente, não tenho me preocupado em “saber exatamente o que tem que mandar”. No EJB 3 tenho mandando os próprios entities para a camada de apresentação remota sem usar DTO. Aí sim o LazyLoad passa a ser uma preocupação… Mas prefiro essa preocupação do que a preocupação de ficar montando e desmontando DTO.

Rede/Banda otimizado? Não creio que vai ser 10K numa requisição RMI que vai deixar as coisas pesadas…

Outra coisa, a discussão não é sobre prever o futuro, só coloquei a questão do projeto desconectado para comparar, pois nesses projetos não dá para usar OpenSessionInView de jeito nenhum. OK?

Realmente é besteira querer deixar a sua camada de aplicação pronta para todo e qualquer cliente que queira se comunicar com o Domain Model…

rodrigoy:

…mas acho que tu não entendeu o que o pattern OpenSessionInView prega. Não estou falando para colocar comandos SQL nos JSPs, estou falando para colocar a ABERTURA e FECHAMENTO da transação na VIEW de forma a encapsular tudo o que acontece na requisição web numa unit of work…

Rodrigo,

So um detalhe.

Se nao estou enganado o que o Open In View prega é a abertura e fechamento de uma Session do Hibernate na View.
Em sistemas web classicos isso normalmente é feito atraves de um filtro.
Mas isso nao me diz que eu preciso manter uma transacao aberta, eu posso ja ter feito commit ou rollback de tudo que eu precisava, mas mantendo a Session aberta isso ja basta para o Open In View.

Pra mim uma coisa é diferente da outra, manter uma Session aberta até na View para poder fazer Lazy Loading é muito mais simples do que colocar o controle transacional no controller.

]['s
]['s

Luca, as coisas estão tão estranhas que você está postando que creio que não estamos falando a mesma coisa!!! :?

Vamos por partes:

1. Sistema Web rodando servlets e JSPs (ou Frameworks Web a escolher) no Tomcat dentro do Jboss tudo numa mesma máquina virtual. Melhor escolha para um controle de abertura e fechamento de transação: OpenSessionInView. Se não concorda poste uma opção melhor…

2. Sistema Desktop rodando Swing + servidor de aplicações, nesse caso, uma máquina virtual no cliente Swing e outra no AppServer. Nesse cenário, não dá para usar OpenSessionInView, pois a UnitOfWork não consegue migrar do client para o server. Você sabe uma maneira transparente da transação ocorrer na camada de apresentação de um sistema remoto?

Luca:

Olá

Sua frase sobre uma única máquina virtual que me refiro é esta e este pattern se chama JavaClipperTabajareitor

Repito, se você se satisfaz com um sistema isolado que exige levar seu computador junto consigo, então use Clipper, VB ou Delphi.

Mas para mim nem agenda pessoal eu admito sem acesso à Internet pois quero acessá-la de onde eu estiver no mundo.

Não tem muita relação o número de máquinas virtuais de uma aplicação e o fato dela viver ou não em isolamento. E muito menos com a escolha de Java, Clipper, VB ou Delphi…

Luca:

Separar a camada de apresentação do acesso ao banco de dados não é introduzir complexidade. É apenas fazer um sistema que sirva para alguma coisa.

Em algum momento a transação tem que ser aberta, fechada ou deu uma exceção que precisa de rollback. O ponto é aonde isso deve ser feito…

Luca:

Cliente desconectado apenas significa que você não tem os demais componentes do sistema instalados e replicados em sua máquina.

Cara, não significa só isso não… acredite em mim, estou desenvolvendo aplicações Swing a mais de 5 anos e a questão do controle transacional ainda é muito precário. É uma luta contra a complexidade e um exemplo é esse post que fiz:

http://www.guj.com.br/posts/list/47015.java

Olá

Rodrigo, eu me ative a sua frase: tudo em uma única JVM.

Quanto a dificuldade de controle transacional com Swing eu não vejo nenhuma porque desde 2000 todos os sistema Swing em que eu participei do desenvolvimento NENHUM acessava a base de dados pela camada de apresentação Swing.

[]s
Luca

Luca:

Olá

Rodrigo, eu me ative a sua frase: tudo em uma única JVM.

Quanto a dificuldade de controle transacional com Swing eu não vejo nenhuma porque desde 2000 todos os sistema Swing em que eu participei do desenvolvimento NENHUM acessava a base de dados pela camada de apresentação Swing.

[]s
Luca

Luca, meus sistemas Swing também não acessam a base pela View! O resumo da arquitetura que estou usando agora é:

Panel -&gt Facade -&gt Domain Model

Nesse modelo, a transação inicia e termina no Facade…

Olá

Só para completar, vou lembrar o que se passou em um antigo projeto durante uma reunião da equipe de desenvolvimento.

A lider da codificação perguntou:

• Mas porque escolheram nossa empresa para fazer este projeto?
  O chefe de tecnologia da empresa respondeu:
• Porque que nós sabemos como fazer o controle das transações com segurança.

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

[]s
Luca

Olá

rodrigoy:

Panel -&gt Facade -&gt Domain Model

Nesse modelo, a transação inicia e termina no Facade…

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.

[]s
Luca

Luca:

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

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:

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á

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 :oops:

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

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, 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.