[SPRING] "@Transactional"은 서비스 레이어 또는 DAO에 있어야합니다.

"@Transactional"은 서비스 레이어 또는 DAO에 있어야합니다.

첫째로 내가 물어보고 이전에 대답 한 것을 요구할 수도 있지만 검색 결과를 다시 얻을 수는 없습니다. 좋습니다 (일반적으로 또는 항상 지금까지 :)) 서비스 계층에 트랜잭션 주석을 정의합니다. 일반적으로 봄철 최대 절전 모드입니다.

Controller-> Manager-> Dao-> Orm.

이제 클라이언트 사이트를 기반으로 도메인 모델을 선택해야하는 상황이 발생했습니다. 클라이언트 A가 내 도메인 모델을 사용하고 있다고 가정하면 모두 좋지만 다른 클라이언트 사이트에서는 웹 서비스를 제공하고 도메인 모델을 사용하지 않을 것입니다.

어떤 레이어를 대체해야합니까? 웹 서비스에서 데이터를 가져와 다시 전송하는 DAO가되어야한다고 생각합니다. 즉 두 개의 Dao 레이어를 별도로 작성하고 시나리오를 기반으로 연결했습니다.

이제 우리는 @Transactional in Service 레이어를 넣을 때 tight coupling을 수행하고 있다는 것을 깨달았습니다. 이렇게 많은 두뇌는 틀릴 수없고 (나는 그것을 의심한다).

그래서 질문은 "어디에서"@Transactional "서비스 레이어 또는 DAO를 배치해야합니까?" 그리고 그것을 아래쪽으로 서비스 레이어로 교체해야합니다.

해결법

1. ==============================

   1.이상적으로, 서비스 계층 (Manager)은 비즈니스 로직을 나타내므로 @Transactional로 주석을 추가해야합니다.

   이상적으로, 서비스 계층 (Manager)은 비즈니스 로직을 나타내므로 @Transactional로 주석을 추가해야합니다.

   서비스 계층은 다른 DAO를 호출하여 DB 작업을 수행 할 수 있습니다. 서비스 메소드에 3 가지 DAO 연산이있는 상황을 가정합니다. 첫 번째 DAO 작업이 실패하면 다른 두 작업이 계속 전달 될 수 있으며 일관성없는 DB 상태가 종료됩니다. 서비스 레이어 주석 달기는 이러한 상황에서 당신을 구할 수 있습니다.

2. ==============================

   2.당신은 당신의 서비스가 트랜잭션이되기를 원할 것입니다. DAO가 트랜잭션 방식이고 각 서비스에서 다른 DAO를 호출하면 여러 tx가 생깁니다. 이는 원하는 것이 아닙니다. 서비스 호출을 트랜잭션 (transaction)로 해, 그 메소드 내의 모든 DAO 호출을 메소드의 tx에 포함합니다.

   당신은 당신의 서비스가 트랜잭션이되기를 원할 것입니다. DAO가 트랜잭션 방식이고 각 서비스에서 다른 DAO를 호출하면 여러 tx가 생깁니다. 이는 원하는 것이 아닙니다. 서비스 호출을 트랜잭션 (transaction)로 해, 그 메소드 내의 모든 DAO 호출을 메소드의 tx에 포함합니다.

3. ==============================

   3.우리는 여러 개의 DAO 구현을 가질 수 있기 때문에 서비스 계층 메소드에 @Transactional을 두는 것이 좋습니다. 이를 통해 우리는 우리의 서비스가 트랜잭션이 될 수있게 만들 수 있습니다. 부치다

   우리는 여러 개의 DAO 구현을 가질 수 있기 때문에 서비스 계층 메소드에 @Transactional을 두는 것이 좋습니다. 이를 통해 우리는 우리의 서비스가 트랜잭션이 될 수있게 만들 수 있습니다. 부치다

   가장 좋은 방법은 일반적인 BasicService를 사용하여 공통 서비스를 제공하는 것입니다.

   서비스는 @Transactional을 배치하기에 가장 좋은 장소이며, 서비스 계층은 논리적으로 트랜잭션을 수행하는 사용자 상호 작용에 대한 세부 수준의 유스 케이스 동작을 유지해야합니다. 이런 식으로 우리는 웹 애플리케이션 코드와 비즈니스 로직 사이의 분리를 유지할 수 있습니다.

   중요한 비즈니스 로직이없는 많은 CRUD 애플리케이션이 있습니다. 컨트롤러와 데이터 액세스 객체 사이를 통과하는 서비스 레이어가 유용하지 않기 때문입니다. 이 경우 Dao에 거래 주석을 넣을 수 있습니다.

   그래서 실제로는 어느 장소 에나 놓을 수 있습니다. 그것은 당신에게 달린 것입니다.

   귀하의 서비스에 여러 번 전화를하면 서비스중인 @Transactional이 필요합니다. @Transactional을 서비스에 넣으면 다른 서비스 호출이 다른 트랜잭션에서 실행됩니다.

4. ==============================

   4.응용 프로그램 유형에 따라 개인 선택입니다. 응용 프로그램이 여러 모듈에 걸쳐 계층화되어 있고 대부분의 작업이 @CRUD 기반 인 경우 서비스 수준에서 트랜잭션 주석을 사용하면 스케줄러, 작업 서버, @ etl과 같은 엔진 유형 응용 프로그램 세션 및 사용자 개념이없는 보고서 응용 프로그램, 컨텍스트 수준에서의 전파 트랜잭션이 가장 적합합니다 ... 우리는 트랜잭션 방지 패턴을 끝내는 모든 트랜잭션을 @transactional을 삽입하여 clusterd 트랜잭션을 생성하지 않아야합니다 ... 어쨌든 실용적인 트랜잭션 제어 JTA2가 가장 적합한 답입니다 ... 다시 한번 주어진 상황에서 사용할 수있는 날씨에 달려 있습니다 ...

   응용 프로그램 유형에 따라 개인 선택입니다. 응용 프로그램이 여러 모듈에 걸쳐 계층화되어 있고 대부분의 작업이 @CRUD 기반 인 경우 서비스 수준에서 트랜잭션 주석을 사용하면 스케줄러, 작업 서버, @ etl과 같은 엔진 유형 응용 프로그램 세션 및 사용자 개념이없는 보고서 응용 프로그램, 컨텍스트 수준에서의 전파 트랜잭션이 가장 적합합니다 ... 우리는 트랜잭션 방지 패턴을 끝내는 모든 트랜잭션을 @transactional을 삽입하여 clusterd 트랜잭션을 생성하지 않아야합니다 ... 어쨌든 실용적인 트랜잭션 제어 JTA2가 가장 적합한 답입니다 ... 다시 한번 주어진 상황에서 사용할 수있는 날씨에 달려 있습니다 ...

5. ==============================

   5.서비스 계층에서 @Transactional을 사용해야합니다. 다른 모델에서 동일한 데이터를 제공해야하는 클라이언트 B의 도메인 모델을 변경하려면 다른 서비스를 제공하거나 DAO 계층에 영향을 미치지 않고 도메인 모델을 변경할 수 있습니다. 인터페이스를 만들고 다른 모델에서 인터페이스를 구현하고 동일한 서비스로 클라이언트를 기반으로 모델을 채 웁니다.이 결정은 비즈니스 요구 사항과 프로젝트의 범위를 기반으로합니다.

   서비스 계층에서 @Transactional을 사용해야합니다. 다른 모델에서 동일한 데이터를 제공해야하는 클라이언트 B의 도메인 모델을 변경하려면 다른 서비스를 제공하거나 DAO 계층에 영향을 미치지 않고 도메인 모델을 변경할 수 있습니다. 인터페이스를 만들고 다른 모델에서 인터페이스를 구현하고 동일한 서비스로 클라이언트를 기반으로 모델을 채 웁니다.이 결정은 비즈니스 요구 사항과 프로젝트의 범위를 기반으로합니다.

from https://stackoverflow.com/questions/3886909/where-should-transactional-be-place-service-layer-or-dao by cc-by-sa and MIT license