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

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.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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 wrote: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.

luis.soares wrote:Também concordo que deva ser na sua camada de negócios.

Obrigado luiz pela sua opinião.

JavaGuru Membro desde: 10/09/2006 21:57:52 Mensagens: 204 Offline

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

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

chicocx wrote: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

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

chicocx wrote: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).

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

rodrigoy wrote: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 wrote: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...

JavaEvangelist Membro desde: 03/12/2006 10:32:50 Mensagens: 491 Online

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_

.

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