Controle de transação - em qual camada deixar?

JavaChild Membro desde: 21/10/2008 20:57:22 Mensagens: 103 Offline

Pessoal boa noite,

pensando em um sistema web, na opnião de vocês em qual camada é mais correto deixar o controle de transações de banco de dados.
Na camada de Apresentação (Action) ou camada de Negócios(Business Object)?

Considerando que estou desenvolvendo um sistema web para faculdade com struts e hibernate.

ou seja

eu tenho

- >>> ACTION - BusinessObject - DAOS

Já fiz tudo só não deleguei ainda para alguém o controle de transações, e aí alguém me da alguma dica?
Quem seria o melhor responsável para tal tarefa?

Abraços

E porque não deixar para o appserver cuidar das transações via JTA para você ao invés de cuidar de tudo na mão?

JavaChild Membro desde: 21/10/2008 20:57:22 Mensagens: 103 Offline

Cara mesmo que seja utilizado JTA é necessário dizer aonde inicia e aonde termina uma transação. E nesse caso eu volto ao mesmo ponto, onde, que no fim das contas falando em camadas significa "quem".

Mas eu já cheguei a uma conclusão para minha situação, o melhor para mim seria deixar esse controle para o Business Object.

Vlw

Em quase todos os casos eu sempre usei CMT, dessa forma o container faz esse controle. Em raros casos precisei usar BMP, mas não lembro de cabeça o motivo.

Mas independente de ser CMT ou BMP o controle da transação sempre deve ficar na camada de negócio, pois é ela que sabe quando há alguma violação de alguma regra. Por exemplo, se você for incluir um usuário você precisa validar se o CPF já existe. Quem irá fazer essa verificação será sua camada de negócio (exemplo, um session-bean), então ele será responsável por saber se deverá ser feito commit ou rollback.

Se você trabalhar com session-beans notará que a transação começa no início da execução do método e termina no final da execução do mesmo. Note que se você chamar 3 métodos de EJB a partir do seu controller você terá aberto e fechado três transações.

Eu não vejo o motivo de você usar o controle de transação em outros locais. A única excessão que eu vejo é quando você está em ambientes não gerenciados o uso de artifícios como o open-session-in-view, porém isso é apenas para casos com JPA ou Hibernate.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

vhmolinar wrote:Cara mesmo que seja utilizado JTA é necessário dizer aonde inicia e aonde termina uma transação. E nesse caso eu volto ao mesmo ponto, onde, que no fim das contas falando em camadas significa "quem"...

Oi, vhmolinar
Isso tb depende da abordagem e do framework de middleware q vc está utilizando, p/ ex.: se vc adota DDD c/ Spring, na "camada" Repository (ou Repositorio) vc poder usar a @Transactional do Spring (ou seja, invariavelmente fica dentro do domain (ou dominio).), sacou??!

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

vhmolinar wrote:Pessoal boa noite,

pensando em um sistema web, na opnião de vocês em qual camada é mais correto deixar o controle de transações de banco de dados.
Na camada de Apresentação (Action) ou camada de Negócios(Business Object)?

Considerando que estou desenvolvendo um sistema web para faculdade com struts e hibernate.

ou seja

eu tenho

- >>> ACTION - BusinessObject - DAOS

Já fiz tudo só não deleguei ainda para alguém o controle de transações, e aí alguém me da alguma dica?
Quem seria o melhor responsável para tal tarefa?

Abraços

Olá!

Como você disse que a sua transação é de Banco de Dados ela tem que logicamente iniciar e terminar no DAO. Nenhum objeto de business por exemplo, tem que saber que a transação do banco ainda esta aberta.
EX: Abre transação, salva objeto, fecha transação.

Agora, se a sua transação for de business, aí ela tem que iniciar e terminar no seu business ( Duhh! )
EX: Abre transação, remove objeto, salva novo objeto, atualiza objeto dependente, termina transação.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

vhmolinar wrote:Cara mesmo que seja utilizado JTA é necessário dizer aonde inicia e aonde termina uma transação. E nesse caso eu volto ao mesmo ponto, onde, que no fim das contas falando em camadas significa "quem".

Mas eu já cheguei a uma conclusão para minha situação, o melhor para mim seria deixar esse controle para o Business Object.

Vlw

Alô, vhmolinar
E aê, poderia dar 1 descrição + detalhada o q é o seu "Business Object" e como vc acabou derfinindo as Transações??!

deniswsrosa wrote:Como você disse que a sua transação é de Banco de Dados ela tem que logicamente iniciar e terminar no DAO. Nenhum objeto de business por exemplo, tem que saber que a transação do banco ainda esta aberta.
EX: Abre transação, salva objeto, fecha transação.

Agora, se a sua transação for de business, aí ela tem que iniciar e terminar no seu business ( Duhh! )
EX: Abre transação, remove objeto, salva novo objeto, atualiza objeto dependente, termina transação.

Mas hein?! Transação na DAO?!?!

Você tem uma transação que começa e termina num momento específico por causa de uma necessidade de negócio. Por isso eu acho que faz mais sentido deixar o controle de transação na camada de negócios. Dependendo do caso, faz mais sentido deixar na camada de aplicação.
De qualquer forma, a camada de infraestrutura tem operações "burras", ele não deveria saber quais operações de alteração de dados devem ser executadas numa determinada transação.

Alguns frameworks como EJB e Spring te permitem demarcar transações na sua camada de negócios ou aplicação de uma forma transparente. Acho esse o melhor cenário. Já o pessoal do Ruby on Rails não se importa muito em deixar o código de transação no meio do código da camada de negócios...

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

Rubem Azenha wrote:..na camada de aplicação.
De qualquer forma, a camada de infraestrutura tem operações "burras", ele não deveria saber quais operações de alteração de dados devem ser executadas numa determinada transação.

Alguns frameworks como EJB e Spring te permitem demarcar transações na sua camada de negócios ou aplicação de ...

como eu havia falado, né?!!

@Rubem Azenha,
O vc quer dizer (especificamente) quando fala "camada de aplicação"?

Uma camada que fica entre a camada de visualização e a camada de negócios/domínio.
Ela não contem regras de negócio nem código referente a visualização do sistema. É apenas coordena algumas atividades executada por objetos da camada de negócio.

Não é sempre que precisamos dessa camada, uma grande vantagem dela é que através dela acabamos construindo uma "API" com as regras de negócio do nosso sistema, que pode ser até exposta para outros sistemas. É um lugar interessante para se colocar o controle de transação.

O livro Domain-Driven Design do Eric Evans chama ela de Application Layer, o PoEAA do Martin Fowler chama ela de Service Layer. A descrição que eles fazem da application layer e service layer é bem parecida em vários aspectos.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

Ah, vc ser refere akela imagem do 'Layered Archterure', c/ a definição das "conceptual layers": UI(Presentation Layer), Application Layer, Domain Layer e Infrastructure Layer??! (não estou c/ o original do Evans, estou c/ akele DDD resumido do InfoQ; depois eu dou 1 revisada na literatura do M. Fowler.)
A propósito, citando: "Application Layer - This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress.", creio q transpondo para o nível de micro-arquitetura a 'Application Layer' equivale exatamente à 'FrontController', não concorda?!!

Rubem Azenha wrote:Uma camada que fica entre a camada de visualização e a camada de negócios/domínio.
Ela não contem regras de negócio nem código referente a visualização do sistema. É apenas coordena algumas atividades executada por objetos da camada de negócio...

Só 1 obs.: esta descrição (logo acima) q vc deu, se assemelha mais com a de 'Service' (o qual até então referencio (costumava referenciar) como Gerenciador/Manager (de Negócio), no qual devemos/podemos codificar o Fluxo de Negócio, nesta qual, IHMO, devem ser codificadas as Transações de Negócio q poder ser Estornadas. Ah, na verdade, a camada 'Service' deve ficar dentro do Domain (Business-Core).

derlon wrote:Ah, vc ser refere akela imagem do 'Layered Archterure', c/ a definição das "conceptual layers": UI(Presentation Layer), Application Layer, Domain Layer e Infrastructure Layer??! (não estou c/ o original do Evans, estou c/ akele DDD resumido do InfoQ; depois eu dou 1 revisada na literatura do M. Fowler.)
A propósito, citando: "Application Layer - This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress.", creio q transpondo para o nível de micro-arquitetura a 'Application Layer' equivale exatamente à 'FrontController', não concorda?!!

Nao... acho que nao tem nada haver com FrontController. Acho que tem mais haver com service layer.

derlon wrote:Só 1 obs.: esta descrição (logo acima) q vc deu, se assemelha mais com a de 'Service' (o qual até então referencio (costumava referenciar) como Gerenciador/Manager (de Negócio), no qual devemos/podemos codificar o Fluxo de Negócio, nesta qual, IHMO, devem ser codificadas as Transações de Negócio q poder ser Estornadas. Ah, na verdade, a camada 'Service' deve ficar dentro do Domain (Business-Core).

Eu acredito que a service layer e a application layer tem propositos parecidos, se nao identicos.

derlon wrote: a camada 'Service' deve ficar dentro do Domain (Business-Core).

De uma olhada nessa figura, que te mostra bem claramente o que o Rubem está explicando:

http://martinfowler.com/eaaCatalog/serviceLayer.html

[]´s
Rodrigo

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

@rodrigo,
Estava me referindo ao 'Service' do DDD (resumo do InfoQ). A propósito, relendo-o acabei me deparando c/ alguma(s) ambiguidade(s)

, q vou comentar no post a seguir...
(Obs.: Aki onde eu trabalho, o site do Fowler (acredite

) é blokeado.)

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