Transação em Repository

This message was edited 1 time. Last update was at 21/03/2011 00:31:00

Ainda não consegui resolver essa questão, e estou começando outro projeto que já vi que vou ter o mesmo problema, então quem puder dar uma dica, agradeceria

Pois meu gerenciador de entidades vai ser injetado por um container de DI, mas eu preciso ter a instância dele para controlar minhas transações, esse é meu problema.

JavaEvangelist Membro desde: 19/07/2006 09:04:42 Mensagens: 402 Offline

Se você gerenciar suas transações nos Repositórios, como vai gerenciar uma transação que envolva mais de um Repositório? Eu acho que transações devem ser gerenciadas por serviços, usando anotações.

esmiralha wrote:Se você gerenciar suas transações nos Repositórios, como vai gerenciar uma transação que envolva mais de um Repositório? Eu acho que transações devem ser gerenciadas por serviços, usando anotações.

Até onde entendi do tópico, tambem acho isso.

j0nny wrote:Mas na minha arquitetura, não tenho service, é só assim:

Controller - Entidades - Repositorios

Penso que deveria haver serviços ou algo similar neste ponto.

flws

esmiralha wrote:Se você gerenciar suas transações nos Repositórios, como vai gerenciar uma transação que envolva mais de um Repositório? Eu acho que transações devem ser gerenciadas por serviços, usando anotações.

Ok, assim é simples pensando em algo como JTA, Spring, mas se eu for gerenciar na mão?

Desculpem a insistência, mas alguém teve uma situação parecida?

j0nny, pelo que sei do assunto, quem deveria gerenciar seu controle transacional seria sua camada de aplicação:

The application layer is responsible for driving the workflow of the application, matching the use cases at hand. These operatios are interface-independent and can be both synchronous or message-driven. This layer is well suited for spanning transactions, high-level logging and security.

The application layer is thin in terms of domain logic - it merely coordinates the domain layer objects to perform the actual work.
http://dddsample.sourceforge.net/architecture.html

The application services in the sample application are responsible for driving workflow and coordinating transaction management (by use of the declarative transaction management support in Spring). They also provide a high-level abstraction for clients to use when interacting with the domain. These services are typically designed to define or support specific use cases. See BookingService or HandlingEventService.

In some situations, e.g. when dealing with graphs of lazy-loaded domain objects or when passing services' return values over network boundaries, the services are wrapped in facades. The facades handle ORM session management issues and/or convert the domain objects to more portable Data Transfer Objects) that can be tailored to specific use cases. In that case, we consider the DTO-serializing facade part of the interfaces layer. See BookingServiceFacade for an example.

Como citado acima, seria um service, mas não um Domain Service, e sim um Application Service.

Acredito que essa seja uma saída válida, por exemplo, se em algum cenário você tivesse que alterar dois Aggregates diferentes em uma mesma transação.

cara, numa aplicação que exige essa complexidade de controle de transação, não usar um framework como o spring + AOP é meio arriscado.

como alternativa pro spring, o Guice seria algo mais "leve"

mas acredito que com AOP vc resolveria facil..

mas de qualquer forma, no caso do DDD, o ideal é controlar transações apartir da camada de aplicação.

fabioFx wrote:cara, numa aplicação que exige essa complexidade de controle de transação, não usar um framework como o spring + AOP é meio arriscado.

como alternativa pro spring, o Guice seria algo mais "leve"

mas acredito que com AOP vc resolveria facil..

mas de qualquer forma, no caso do DDD, o ideal é controlar transações apartir da camada de aplicação.

Então ele teria
Controller -> Application -> Entity -> Repository?

muitos consideram a camada de controle como parte da application, outro consideram que application está dentro do controller..

pra mim as duas são a mesma coisa.. hehe

mas a idéia do teu fluxo está correta.. mesclando o controller e o application.
eu pessoalmente colocaria entre o application e o entity uma classe Service (domain), no caso do dominio do problmema q vc exemplificou..

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3161 Offline

pq não poem um Facade no meio e gerencia as transações atravez dele?

luistiagos wrote:pq não poem um Facade no meio e gerencia as transações atravez dele?

mas esse é o objetivo do Service, mas quem gerencia a transação é a Application..

Andre, e por curiosidade, vc ta usando hibernate/jpa na impl. do repository?

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