"@Transactional"은 서비스 계층 또는 DAO를 배치해야 하는 위치

"@Transactional"은 서비스 계층 또는 DAO를 배치해야 하는 위치

우선, 이전에 질문하고 대답한 적이 있는 것을 묻고 있을 가능성이 있습니다만, 검색 결과를 얻을 수 없었습니다.서비스 레이어에 트랜잭션 주석을 정의합니다.일반적으로 봄 휴지 상태 crud는

컨트롤러 -> 매니저 -> Dao -> Orm.

클라이언트 사이트에 따라 도메인 모델 중 하나를 선택해야 하는 상황이 되었습니다.클라이언트 A가 내 도메인 모델을 사용한다고 가정하면 모든 것이 좋지만 다른 클라이언트 사이트에서 웹 서비스를 제공하고 우리의 도메인 모델을 사용하지 않을 것입니다.

어느 레이어를 교환해야 합니까?웹 서비스에서 데이터를 가져와 다시 전송하는 DAO가 필요합니다.즉, 시나리오에 따라 별도로 작성된 두 개의 DAO 레이어를 연결하고 있습니다.

나는 우리가 (그런 것이 있거나 느슨하지 않다고 말할 때) 긴밀하게 결합을 해왔다는 것을 깨달았다.@Transactional서비스 레이어에 있습니다.그렇게 많은 두뇌가 틀릴 리는 없다. 그렇지 않을 수도 있다.

그래서 질문은 "어디서 해야 하는가?"입니다.@Transactional"be placed Service Layer or DAO?"는 대체해야 할 서비스 계층이 아래쪽에 있습니까?

---

11년이 지났지만 여전히 관련성이 있습니다.프로젝트를 돌이켜보면 그 당시 도메인 모델에 대한 저의 이해에 분명히 문제가 있었습니다.저는 ORM 레이어를 도메인 모델로 생각하고 있었습니다.또, ORM 및 독립 엔티티와 작업하고 싶었고, 데이터 매핑도 없고, DTO도 없었습니다.그게 요즘 대세였어요.현재 도메인 모델은 ORM이 아니며 적절한 도메인 모델을 가지고 있으며 ORM 또는 Webservices를 사용하는 것이 데이터 소스입니다.많은 사람들이 지적한 바와 같이, 예, 서비스가 적절한 장소이며, 적절한 도메인 모델을 가지고 있으며, JPA(ORM)를 도메인 모델로 간주하지 않습니다.

서비스 계층(매니저)은 비즈니스 로직을 나타내므로 다음과 같이 주석을 달아야 합니다.@Transactional.

서비스 계층은 DB 작업을 수행하기 위해 서로 다른 DAO를 호출할 수 있습니다.서비스 방법에 3개의 DAO 작업이 있다고 가정합니다.첫 번째 DAO 작업이 실패한 경우 다른 두 개의 작업이 여전히 통과되어 일관성 없는 DB 상태가 될 수 있습니다.서비스 계층에 주석을 달면 이러한 상황을 피할 수 있습니다.

당신은 당신의 서비스가 트랜잭션되기를 원할 것입니다.DAO가 트랜잭션이고 각 서비스에서 서로 다른 DAO를 호출하는 경우 여러 트랜잭션이 발생합니다. 이는 원하는 트랜잭션이 아닙니다.서비스 콜을 트랜잭션으로 하면 이러한 메서드 내의 모든 DAO 콜이 메서드의 트랜잭션에 참여합니다.

여러 DAO를 구현할 수 있기 때문에 @Transactional을 서비스 레이어 메서드에 넣을 것을 제안합니다.이것에 의해, 우리의 서비스를 트랜잭션화 할 수 있습니다.언급하다

Best Practice는 일반적인 Basic Service를 사용하여 공통 서비스입니다.

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

중요한 비즈니스 로직이 없는 CRUD 어플리케이션이 많이 있습니다.컨트롤러 간에 데이터를 통과시키는 서비스 레이어가 있는 경우 데이터 액세스 오브젝트는 유용하지 않습니다.이 경우 트랜잭션 주석을 Dao에 추가할 수 있습니다.

따라서 실제로는 어느 장소에나 설치할 수 있습니다.그것은 당신에게 달려 있습니다.

서비스에 여러 개의 콜이 있기 때문에 @Transactional in Service가 필요합니다.@Transactional을 서비스 상태로 하면 다른 트랜잭션으로 다른 콜이 실행됩니다.

어플리케이션 타입에 따라 달라집니다.어플리케이션이 여러 모듈에 걸쳐 레이어드 되어 있고 대부분의 조작이 @CRUD 기반인 경우 서비스레벨에서 @transactional annotation을 사용하면 보다 센스가 높아집니다.scheduler, job server, @etl 보고서 앱 등의 엔진 타입 어플리케이션.세션과 사용자 개념이 존재하지 않는 경우 컨텍스트 수준의 전파 트랜잭션이 가장 적합합니다.모든 곳에 @productional을 배치하여 clusterd 트랜잭션을 생성해서는 안 됩니다.어쨌든 실용적인 트랜잭션 제어에 있어서 JTA2가 가장 적합한 답입니다.다시 말씀드리지만, 그것은 주어진 상황에서 사용할 수 있는 날씨에 달려 있습니다.

@Transactional at service layer를 사용해야 합니다.클라이언트 B의 도메인 모델을 변경하려면 다른 서비스를 제공하거나 인터페이스를 생성하여 다른 모델과 sa를 사용하여 인터페이스를 구현함으로써 DAO 레이어에 영향을 주지 않고 도메인 모델을 변경할 수 있습니다.me service는 클라이언트를 기반으로 모델을 채웁니다.이 결정은 비즈니스 요건과 프로젝트의 범위에 따라 결정됩니다.

나는 프로그래밍 수업에서 dao 계층이 데이터베이스와의 상호작용을 담당한다는 것을 들었다. 그리고 서비스는 dao와 함께 할 수 있는 일련의 작업이다. 따라서 데이터베이스와 관련이 없다. 그리고 작업 집합은 하나의 트랜잭션으로 이루어지며, 평균은 더 나은 서비스 트랜잭션이다.

언급URL : https://stackoverflow.com/questions/3886909/where-should-transactional-be-placed-service-layer-or-dao