DTO가 뭘까?
Data Transfer Object
데이터 전송 객체 : 데이터를 전송하기 위해 사용하는 객체
-> Entity 대신 ‘사본’처럼 일할게라고 하는 녀석이다.
Entity : DB 1:1로 매핑되는 객체
DB에 들어가기 위해서는 검증이 되어야 한다.
유의미한 정보들만이 들어가야한다.
그런데 이러한 과정에서 Entity는 Controller까지 왔다갔다 하기에는 위험해보인다. 또한, 만약에 사용자가 입력하는 정보와 DB에 저장해야하는 방식이 다르다면 어떻게 할까? 예를 들면 사용자들은 년도로 입력받고 DB에는 나이로 저장을 한다면 어떻게 할까? 또한 입력받은 값을 그대로 DB에 저장해야 한다면 문제가 있을 것이다. 화면이 바뀌면 DB도 Entity도 바뀌어야 한다면 그것 또한 큰 문제일 것이다. 이러한 문제들로 위해 DTO를 사용한다. 그렇다면 DTO와 Entity를 바꾸고 연결해주는 건 누굴까?
정리
위의 문제들을 해결하기 위해 일반적으로 DTO(Data Transfer Object)가 사용된다. DTO는 데이터를 전송하기 위한 객체로, 주로 서로 다른 레이어 간에 데이터를 전송할 때 사용된다. 보통 엔터티(Entity)와는 다르게 비즈니스 로직을 가지지 않고 순수하게 데이터를 담고 전달하는 역할을 한다.
DTO는 사용자가 입력한 데이터를 받아들이고, 필요에 따라 데이터를 변환하여 엔터티에 전달하는 역할을 한다. 따라서 사용자가 입력한 정보와 엔터티에 저장되는 정보의 형식이 다를 경우에도 DTO에서 이를 처리할 수 있다. 예를 들어, 사용자가 년도로 입력한 정보를 DTO에서 나이로 변환하여 엔터티에 전달할 수 있다.
그리고 DTO는 컨트롤러(Controller)와 서비스(Service) 레이어 간에 사용되는데, 보통 컨트롤러에서 DTO를 받아들이고, 서비스 레이어에서 DTO를 엔터티로 변환하여 비즈니스 로직을 처리하고, 다시 DTO로 변환하여 컨트롤러에 전달한다.
따라서 DTO를 생성하고 변환하는 작업은 일반적으로 서비스 레이어에서 처리된다. 이는 엔터티와 DTO 사이의 매핑 및 변환을 담당하는 서비스 혹은 유틸리티 클래스에서 수행된다. 이런식으로 DTO를 사용하면 엔터티와의 결합도를 낮추고, 유연하고 확장 가능한 구조를 유지할 수 있다.
- 지금까지의 코드를 보며, Entity <-> DTO 변환을 어디서 할 건지 결정해주세요.
- 변환 방법에는 어떤 것들이 있나요? 그 중 어떤 방법을 선택하실 건가요~?!
-
변환은 Service에서 진행할 것이다! 서비스 계층에서 비즈니스 로직을 처리하는데 이러한 DTO와 Entity간 로직의 변경은 비즈니스 로직이라고 생각되기 때문이다.
-
수동 변환과 모델 매퍼 사용이 있다. (잘 몰라서 구글링을 통해 참조했습니다.) 수동 변환이란 개발자가 직접 Entity와 DTO 사이의 필드를 매핑하고 변환하는 방식이다. 간단하고 직관적이지만 변환 작업이 반복될 경우 코드 중복이 발생할 수 있다. 모델 래퍼는 자동화된 방식으로 Entity와 DTO 사이의 필드를 매핑하고 변환하는 라이브러리다. 변환 작업을 자동화하고 코드 중복을 최소화할 수 있으며 유지 보수성이 좋다. 하지만 나는 이러한 장점에도 불구하고 수동 변환을 통해 변환해볼 생각이다. 왜냐하면 먼저 이런 수동으로 해보고 불편함을 느끼며 왜 라이브러리가 생겼는가에 대해 생각해볼 수 있고 이를 이해할 수 있다고 느끼기 때문이다.
