Entity
Entity 클래스를 가장 잘 나타내는 한문장은 "실제 DB 테이블과 매핑되는 클래스"일 것 같다. 이와 같이 Entity는 데이터베이스의 테이블에 존재하는 컬럼들을 필드로 가진다. Entity에 대해서 기억해둬야 할 점을 적어둔다.
- DB 테이블과 1대1로 매핑된다
- DB 테이블이 갖지 않는 필드를 가져서는 안된다.
- Request나 Response 값을 전달하는 클래스로의 사용은 옳지 않다.
- 상속을 받거나 구현체여서는 안된다.
- 서비스 클래스나 비즈니스 로직들이 이 Entity를 중심으로 설계가 된다.
- setter를 지양해야 한다.
DTO
Data Transfer Object의 줄임말로 말 그대로 DATA 전달이 주 목적인 클래스이다.
- 비즈니스 로직을 포함하지 않는다.
- Controller와 같이 외부와 직접적으로 마주하는 계층에서는 이 DTO를 사용해서 데이터를 교환한다.
- View와 통신할 때 사용되게 된다.
- Mapper를 따로 정의하여 상황에 맞춰 DTOToEntity, EntityToDTO등을 통해 class 변환을 이끌어낸다.
- API 요구사항에 따라 쉽게 변경될 수 있다.
Entity와 DTO를 구분해서 사용하는 이유
-
Entity 구현과 그 자체를 안전하게 숨길 수 있다.(역할의 분리)
사실 Entity가 View를 그리는 정보를 전달할 수 ? 당연히 있다. 이미 데이터는 다 가지고 있기 때문이다. 다만 Entity는 DB 직접적으로 연결되어 핵심 로직들을 지니고 있는데, 이게 밖으로 노출될 경우 의도치 않은 상황에서 수정이 일어나버릴 수 있게 된다. -
데이터를 선별적으로 보내줄 수 있다.
서비스가 커지는 상황을 생각해보자. 하나의 Entity가 담는 정보도 증가하겠지만 무엇보다도 다양한 화면에서 여러 data들을 요구하게 될 것이다. 그렇다 보면 각 화면에서 필요로 하는 데이터가 다를텐데, Entity를 넘기다 보면 불필요한 데이터들을 매번 넘기게 되고 이는 자연스럽게 속도의 저하로도 이어진다. 이에 반해 DTO를 사용하면 필요한 데이터만 딱딱 넘길 수 있게 된다. -
순환참조를 예방할 수 있다.
내가 지금 공부하려고 하고 있는 JPA에서 쌍방향으로 참조를 하고 있으면 Entity를 불러오면 lazy loading이 되고, 되고, 되면서 순환참조 문제가 생기게 된다. 따라서 요청의 response를 DTO로 보내주게 되면 이런 문제를 해결할 수 있다. -
validation 로직을 분리할 수 있다.
다른 내용들은 어느정도 알고 있었다면 이 내용은 미처 생각을 못했는데 유용할 것 같다. 결국 데이터가 들어오는 그 앞단에서 DTO를 통해 검증을 진행할 수 있게 된다는 장점이 있는 것이다.
