SpringBoot와 같은 프레임워크가 이렇게 많은 일을 할 수 있다는 것은 좋은 일입니다.

JPA 엔터티 클래스와 간단한 저장소 인터페이스만 있으면 SpringData는 일반적인 CRUD 데이터베이스 작업에 필요한 모든 것을 제공합니다.

간단한 REST 컨트롤러 클래스를 작성하고 REST API가 실행되고 있죠?

안녕하세요, 그런데 DTO 작성을 잊으셨나요? 그런데 앱이 없어도 작동할 수 있는데 실제로 왜 필요한가요?

확실히 몇 가지 일반적인 이유가 있습니다:

• 계층 구조(예: 육각형 아키텍처 또는 포트 및 어댑터): 유지 관리를 위해 외부 통신 코드를 핵심(비즈니스 로직)에서 분리하는 것이 좋습니다.
• 보안 및 성능: API에 데이터베이스 구조를 있는 그대로 노출한다면 곧 필요 이상으로 노출되는 지점에 도달하게 될 것입니다. 악의적인 행위자가 오용하거나 리소스(CPU, 메모리, 네트워크 대역폭)를 낭비할 수 있음
• JPA 엔터티와 달리 DTO는 변경할 수 없으며(Java 레코드 사용 가능) 데이터 기반(기능적) 프로그래밍 스타일, 좋은 단위 테스트, 안전한 동시성 등에 적합합니다.

하지만 다른 이상한 일도 일어날 수 있습니다. 제 경험을 바탕으로 이상한 예를 하나 보여드리겠습니다.

이 GitHub 저장소에는 DTO 없이 작동하는 간단한 애플리케이션이 포함되어 있습니다. 사용자 엔터티가 있으며 각 사용자는 여러 트랜잭션을 가질 수 있습니다. 저장소와 RestController 사이에 서비스 빈이 있어 가능한 데이터베이스 액세스 예외를 포착합니다.

우리는 프로덕션에 준비된 애플리케이션을 만들고 싶기 때문에 Hibernate가 DDL을 생성하는 것을 원하지 않습니다. 대신 테이블을 생성하는 Schema.sql이 있습니다(나중에 Flyway 또는 Liquibase로 전환할 수 있음). 간단한 예에서는 테이블이 비어 있지 않도록 data.sql도 있습니다.

애플리케이션을 실행하고 http://localhost:8080/users에서 API 엔드포인트를 호출하면 사용자와 해당 트랜잭션이 포함된 예상 JSON을 얻습니다.

이제 //!!로 표시된 Transaction 클래스의 두 줄의 코드에 주목해 보겠습니다.

@JsonIgnore //!!

첫 번째 냄새는 Transaction 클래스에서 User 참조에 @JsonIgnore 주석을 추가해야 한다는 것입니다. 해당 주석이 없으면 무한 재귀로 인해 JSON 직렬화가 충돌합니다.

이제 누군가가 Transaction 엔터티에 다른 필드(설명)를 추가하여 실수를 했지만 SQL 문을 조정하는 것을 잊어버린 경우(또는 스키마 변경이 적용되지 않은 환경에서 애플리케이션을 실행하는 경우)를 가정해 보겠습니다.

비공개 문자열 설명;//!!

물론 이제 API 호출이 실패합니다. 하지만 오류 처리를 살펴보세요! UserService 내부의 catch 절이 예상대로 작동하지 않습니다. 대신 로그에서 이상한 스택 추적을 볼 수 있습니다:
GlobalExceptionHandler: 예기치 않은 오류 org.springframework.http.converter.HttpMessageNotWritableException: JSON을 쓸 수 없습니다:

한 번은 이 상황을 본 적이 있으며(분명히 이 예제보다 훨씬 더 큰 애플리케이션에서) SQL 예외가 서비스를 이스케이프한 이유와 HttpMessageNotWritableException이 발생하는 이유를 이해하는 데 꽤 시간이 걸렸습니다. 보이시나요?

일어나는 일은 UserService 클래스(UserRepository를 통해)가 USERS 데이터베이스 테이블만 쿼리한다는 것입니다. 기본 Hibernate 지연 로딩으로 인해 트랜잭션 엔터티는 결과의 일부가 아닙니다. Jackson deserializer가 User 인스턴스에서 JSON을 생성하려고 시도할 때만 Hibernate가 Transaction 엔터티를 가져오도록 하는 getTransactions 메서드를 호출합니다.

이것이 JSON과 SQL을 결합한 이상한 스택 추적을 얻는 이유입니다. 예외는 어떻게 해야 할지 모르는 GlobalExceptionHandler에 의해 포착됩니다. 이것이 로그 메시지가 "예기치 않은 오류"인 이유입니다.

이 작은 연습을 통해 애플리케이션의 여러 레이어를 혼합하는 것이 얼마나 위험한지 더 깊이 이해할 수 있기를 바랍니다. 애플리케이션이 아직 작을 때 애플리케이션의 "맑은 날" 시나리오만 보면 일부 개발자는 너무 늦을 때까지 계속해서 잘못된 작업을 수행하게 될 수 있습니다.

DTO와 애플리케이션의 다른 계층 사이의 필드를 매핑하는 상용구 코드를 작성할 필요가 없습니다. MapStruct가 대신해 드립니다.