[Spring] DTO와 Entity, 왜 분리해서 사용할까?

프로젝트를 하다가 controller에서 reviewCheck 라는 값을 Y로 변경시켜야하는 코드를 보다가 든 의문이다.

//Controller
//리뷰 등록 여부 체크
service.regReviewCheck(reviewDTO);

//ServiceImpl
//리뷰 등록 여부 체크
	@Override
	public void regReviewCheck(ReviewDTO reviewDTO) {
		Optional<RegisterEntity> registerEntity = registerRepository.findByUseridAndClassCode(reviewDTO.getUserid(), reviewDTO.getClassCode());
		RegisterEntity register = registerEntity.get();
		register.setReviewCheck("Y");		
		registerRepository.save(register);
	}

이렇게 service에서 register.setReviewCheck('Y')를 통해서 reviewCheck를 Y로 변경시켜줄 수도 있고,

//리뷰 등록 여부 체크
registerDTO.setReviewCheck('Y');

그냥 DTO에 reviewCheck를 추가해서 setReviewCheck('Y')로 변경시켜줄 수도 있다.

둘 다 가능은 하지만 DTO를 사용하는 두번째 방법이 훨씬 짧고 편한데, 첫번째 방법을 쓰는 이유는 무엇일까 하는 생각이 들어서 찾아보았다.

 

DTO와 Entity

DTO(Data Transfer Object)는 데이터 전송만을 위한 객체로, 비즈니스 로직을 포함하지 않는다, 외부로 노출 시 계층 간의 결합도가 높아질 수 있다.

Entity는 로직(메서드)과 데이터 상태를 포함한다. 로직을 포함하지 않아서 외부 계층에서도 사용할 수 있다,.

데이터를 가공하지 않고 단순히 보여주는 용도로 사용할 때는 DTO를 사용하는 것이 더 적합하고,
데이터가 로직에 따라 변경되어야 하는 경우에는 Entity를 사용하는 것이 더 적합하다.

이렇게 분리해서 사용하면 다음과 같은 장점이 있다.

1. 결합도를 감소시킬 수 있다

 엔티티와 DTO로 분리하여 사용하면 서로의 변화에 영향을 덜 받을 수 있다. 엔티티의 내부 구현이 바뀌더라도 DTO의 구조나 외부 인터페이스에 영향을 주지 않는다.

2. 유연성이 증가한다

 엔티티는 로직을 포함한 도메인 모델의 개체이고, DTO는 데이터 전송 모델의 개체이다. 엔티티와 DTO를 분리하면 도메인 모델과 데이터 전송 모델 각각을 독립적으로 수정하고 확장할 수 있다.

3. 표현의 분리할 수 있다

 외부 시스템과의 데이터 교환을 위해서는 엔티티의 내부 구조나 데이터베이스 스키마에 종속되지 않고, 필요한 데이터를 외부로 표현해야 한다. 이 때 DTO가 쓰인다.
 예를 들자면, 회원 정보를 담는 member라는 엔티티가 있다. 이 엔티티에는 사용자의 아이디, 이름, 이메일, 주소, 성별 등이 포함되어 있다. 그러나 아이디 찾기를 진행해서 아이디를 노출시키려면 이름과 아이디만 필요하다. 이 때 엔티티 전체를 전송하지 않고 DTO에 이름과 아이디만 담아서 전송할 수 있다. 이렇게 하면 엔티티의 내부 구조와 비즈니스 로직에 대한 의존성을 낮추면서, 필요한 정보만 간결하게 표한할 수 있다.

 

근데 여기서 주의할 점! DTO라고 데이터 가공을 하지 못하는 것은 아니다. 위의 코드처럼 DTO도 데이터를 가공할 수 있다.

DTO는 데이터를 보관하고 전달하기 위한 용도로 설계되고, 주요 목적이 데이터의 전송이나 교환을 위한 용도이기 때문에 그러한 용도로 쓰는 게 위의 장점들도 포함하면서 바람직할 뿐이다.

하지만 때에 따라서는 DTO에 가공 작업이 필요한 경우가 있을 수 있는데, 그 중 대표적인 하나는 클라이언트가 입력한 데이터가 가공되어야 하는 경우이다. 예를 들어, 전화번호를 입력받을 때 하이픈을 제거하거나, 특정 형식에 맞게 가공하는 등의 경우가 있다.