Tenho um projeto com as camadas:
Visao -> controle -> negocio -> persistencia -> banco
e um pojo 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…
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.
[quote=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.[/quote]
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
[quote=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.[/quote]
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
[quote=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…
[/quote]
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).
[quote=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.[/quote]
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)”?
[quote=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)”?[/quote]
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.
[quote=chicocx]Acredito que seja na camada de negocio mas o pessoal aqui na empresa insiste que deve ser no controle…
[/quote]
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á
[quote=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.[/quote]
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
[quote=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 [/quote]
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…