데이터 전송 개체 및 트랜잭션 서비스 방법

Question

Hibernate 지원 트랜잭션 서비스 방법을 통해 데이터를 전달할 때 DTO 사용을 피하는 실제적인 방법이 있습니까?즉, DTO는 초기화 지연 문제를 방지하는 유일한 해킹되지 않은 솔루션입니까?

DTO에 대한 두 가지 인기 있는 대안과 이를 별로 좋아하지 않는 이유는 다음과 같습니다.

1. 보기 패턴에서 세션을 엽니다.나는 서비스 방법을 실제로 트랜잭션 방식으로 유지하고 싶기 때문에 이것을 좋아하지 않습니다(예:Hibernate 세션은 메소드가 종료될 때 커밋되고 닫힙니다.이는 주로 예를 들어 나중에 서비스를 웹 서비스로 게시해야 하는 경우 트랜잭션에 대해 걱정할 필요가 없기 때문입니다.

2. DTO 대신 서비스 메서드를 통해 도메인/비즈니스 개체를 전달하고 필요한 속성/속성을 열심히 가져옵니다.이것이 다소 좋습니다.그러나 복잡한 엔터티 관계가 있는 중요하지 않은 도메인 개체 계층에서는 열성적인 가져오기가 어딘가에서 중지되어야 합니다.그리고 그렇게 되면 이것이 어떻게 전체의 참조 ID로 엔터티를 대체하는 완전한 해커톤으로 빠르게 바뀌지 않을지 알 수 없습니다.

내가 뭔가를 놓치고 있는 걸까요? 아니면 실제로 DTO가 유지 관리 관점에서 볼 때 유일한 확실한 접근 방식인가요?

Answer 1

엔터티를 실제로 사용하는 유일한 방법은 OpenSessionInView보다 조금 더 정교한 것을 사용하는 것입니다.내 경험에 따르면 애플리케이션 수준에서 최대 절전 모드 세션을 수동으로 관리해야 합니다.OpenSessionInView는 하나의 요청에 대해서만 동일한 세션을 제공합니다.그 후에는 현재 세션에 지속적으로 다시 연결해야 합니다.Seam과 대화를 살펴보거나 자신만의 Hibernate 세션 관리를 구현해 보세요.현재 우리는 마법사가 시작하고 끝나는 시점을 기준으로 세션을 수동으로 관리하고 Spring AOP를 사용하여 적시에 적절한 스레드에 세션을 연결합니다(세션은 스레드로부터 안전하지 않으며 AJAX와 잘 혼합되지 않습니다).

반면에 WebServices에는 어떤 형태의 DTO가 필요할 것입니다.나는 그 주위에 방법이 보이지 않습니다.엔터티는 POJO처럼 보일 수 있지만 실제로는 그렇지 않습니다. 직렬화하는 것은 어려운 것부터 거의 불가능한 것까지 다양합니다.서비스 방법의 목표에 맞는 DTO를 생성하고 완료하면 됩니다.

개인적으로 나는 DTO 패턴이 끔찍하다고 생각하지 않습니다. 웹 사이트를 만드는 중이라면 엔터티를 사용하여 엔드투엔드 방식을 사용하는 것이 가능하며 일부 성능을 얻을 수도 있지만 더 유연한 아키텍처를 원한다면 계속 사용하세요. DTO.

Answer 2

저장소, 서비스 및 컨트롤러는 애플리케이션 코어를 다루는 장소입니다 (최대 절전 모드 세션은 원하는 경우 리포지토리 레이어 전체로 사용할 수 있음).

뷰는 도메인 모델 인 애플리케이션 코어를 다루지 않아야합니다. 그들은 살아있는 물체를 다루지 말고 살아있는 객체의 비현실적인 맞춤형 표현을 다루어야합니다. 뷰는 필요한 데이터만으로도 필요한 데이터 만 건네야합니다. 당신은 당신의 견해를 위해 dtos를 구축해야합니다. 이 패턴은 도메인 모델과 대조하기 위해보기 모델이라고도합니다.

삶을 편하게하기 위해 도메인 모델 객체에서 뷰 모델 객체로 자동 맵을 자동 매핑 할 수있는 라이브러리 나 프레임 워크가있을 수 있습니다. .NET에는 현재 개발중인 Automapper라는 오픈 소스 프레임 워크가 있습니다. 자바에 무엇이 있는지 잘 모르겠습니다.

Answer 3

세션을 닫도록 요구 사항을 완화하더라도 보기에서 열린 세션을 계속 사용하고 서비스 트랜잭션의 모든 것을 커밋할 수 있습니다.세션은 여전히 ​​지연 가져오기에 사용할 수 있지만 모든 트랜잭션은 완료됩니다.그러나 웹 서비스로 전환하려면 어쨌든 모든 엔터티를 즉시 로드해야 합니다.DTO는 의식적으로 열성적인 로드를 강요하고 우발적인 게으름을 방지합니다.

따라서 조심한다면 두 환경 모두에서 DTO를 건너뛸 수 있지만 아마도 열린 세션을 계속 유지하고 웹 서비스가 실제로 요구 사항이 될 때 웹 서비스에 대해 걱정할 것입니다.

Answer 4

나는 DTO의 아이디어를 좋아하지만, 데이터베이스까지의 접근 방식을 적절하게 구현하기 때문에 일반적으로 많은 노력이 필요하기 때문에 항상 다른 개발자들이 잘 받아 들여지거나 좋아하지 않았다고 느꼈습니다. 이것이 제가 만든 이유입니다 Blaze-Persistence Entity Views DTO를 효율적인 방식으로 JPA 엔티티 모델에 매핑하는 인터페이스로 DTO를 모델링 할 수 있습니다. 엔티티 뷰를 쿼리에 적용 할 수 있으며 쿼리는 모든 주가 아닌 실제로 필요한 상태를 가져 오는 방식으로 만 조정됩니다.

엔티티 뷰를 사용하면 원하는 구조가 간절히로드되기 때문에 뷰 방지 방지 시야에서 열린 세션이 필요하지 않습니다. 엔티티 객체가 관련되어 있지 않기 때문에 게으른 로딩 문제도 없습니다.

엔티티 모델은 종종 초기 개발 단계에서 DTO 모델과 매우 유사하기 때문에 개발자는 번거 로움을 피하려고 할 때 별도의 DTO 모델을 만드는 것만 종종 볼 수 있습니다. 감사, 통계 또는 피식과 같은 교차 절단 문제가 엔티티 모델에 착륙하거나 엔티티 모델의 데이터 양이 엔터티의 사용 사례에 실제로 필요한 것보다 훨씬 커지면 개발자는 문제가 발생합니다.

당신은 확실히 a를 좋아할 것입니다 블로그 게시물 그 문제에 대해 나는 얼마 전에 썼습니다.