[TIL] DTO 란?

nest 공부를 하다보니 DTO, Entity 라는 개념을 자주 듣게 되어 그것이 무엇인지 정리해보는 시간을 가지려고 합니다.

Entity

Entity란 쉽게 말하면 하나의 실체라고 할 수 있습니다. DB 테이블에 존재하는 Column들을 필드로 가지는 객체를 말합니다. Entity는 DB의 테이블과 1대 1로 대응되며, 때문에 테이블이 가지지 않는 칼럼을 필드로 가져서는 안됩니다. 또한 Entity 클래스는 다른 클래스를 상속받거나 인터페이스의 구현체여서는 안됩니다.

현재 제가 이해하고 있는 방식으로는, 하나의 테이블 또는 객체가 바로 entity다 라고 이해하고 있습니다.

DTO

DTO는 Data Transfer Object의 약자로 프로세스 간 데이터를 전달하는 객체를 의미합니다.
백엔드에서 요청을 받고 응답하는 과정에서 데이터를 호출하는 것은 상당한 비용을 필요로 합니다. 따라서 이 비용을 최소화하기 위해서는 요청 횟수를 최소화하고, 한 번의 요청에 최대한 효율적으로 많은 데이터를 보내야 합니다. 이를 쉽고 간단하게 만들기 위해 DTO가 고안되었다고 생각하시면 됩니다. 즉, 데이터의 타입과 validation 등을 체크하고, 추가적인 로직을 더해 한번의 통신에서 데이터를 최대한 많이, 그리고 적합하게 통신하기 위한 방식이라고 보시면 됩니다.

현재 제가 이해하고 있는 방식으로는, 데이터를 주고 받는 하나의 양식이자, 실체 라고 생악하고 있습니다.

DTO와 Entity의 차이점

그렇다면 일견 비슷해보이는 DTO와 Entity의 차이점은 무엇일까요?
이 둘의 차이는 어느 정도의 계층에 관여하냐의 차이라고 볼 수 있습니다. Entity의 경우 실제 테이블과 매핑되어 만일 변경할 경우 이와 관련한 수많은 클래스에 영향을 끼치게 되기 때문에 통신을 주고 받는 데이터를 Entity로 관리하게 될 경우 유지보수가 어려울 뿐더러, 예기치 못한 사이드이펙트가 발생할 수도 있습니다.
반면, DTO는 view와 자주 통신하는 계층에 관여하기 때문에, Entity에 비해 훨씬 유동적입니다. Entity로 정의된 데이터를 복제하여 이를 가공 후, view로 보내는 역할을 하기 때문에 이 부분에서 데이터를 수정하고 로직을 추가하는 것이 관리 및 유지보수라는 측면에서 큰 이점을 가질 수 있습니다.

이렇게 정리를 했지만, 아직 Entity와 DTO에 대해서 명확하게 와닿지는 않네요.
앞으로 계속 공부하고 주변에 질문하면서 이 개념을 확실하게 잡아나가야 할 것 같습니다.