Spring : Entity와 DTO 역할 분리

Entity와 DTO 역할 분리

현재 실무에서도 Entity와 DTO 분리 없이 Entity 하나로만 운영하는 사람들도 많다고 한다.

하지만 Entity 하나로만 운영하게되면 큰 문제점들이 존재한다.

나 역시도 이전 글에서 Entity를 view에 그대로 반환하는 방법으로 계층간의 데이터 전송의 역할로 직접 활용했었다.

그래서 나는 이 글에서 Entity와 DTO의 개념, 역할 분리의 필요성을 기술하고

Entity를 DTO 변환하는 방법, 반대로 DTO를 Entity로 변환하는 방법을 기록해볼 것이다. 

---

Entity

Entity는 실제 데이터베이스의 테이블에 매핑되며 테이블에 존재하는 컬럼들을 필드로 가지는 객체이다.

데이터베이스의 테이블과 1:1로 매핑되며, 테이블이 가지지 않는 컬럼을 필드로 가져서는 안된다.

즉, 웹 애플리케이션에서 실질적인 데이터 구조를 나타내고있어 데이터베이스의 구조가 변경되면 Entity 클래스도 함께 수정해야 한다.

Entity는 비즈니스 로직을 포함 시킬 수 있어, 이를 통해 도메인 모델을 표현하는데 주로 사용된다.

또한 Entity는 영속성 컨텍스트 계층에서 사용되는데 영속성(pesistent) 목적으로 사용되는 객체이기 때문에 요청(Request)이나 응답(Response) 값을 전달하는 클래스로 사용하는 것은 좋지 않다.

DTO (Data Transfer Object)

DTO는 클라이언트와 서버 계층간에 데이터를 전송하기 위해 사용하는 객체이다.

DTO는 순수하게 데이터를 저장하고, 데이터에 대한 getter와 setter만을 가져야하고 비즈니스 로직을 포함하지 않으며, 오로지 데이터 전송만을 위한 캡슐화 객체로써 동작한다.

DTO는 필요한 데이터만 담아 전송할 수 있어 클라이언트에게 노출할 필요가 없는 패스워드 등의 민감한 정보를 제외하는 등 필요한 필드만 선택적으로 포함하는 구조를 가지고 있다. 

따라서 DTO는 클라이언트 요청(Request)이나 응답(Response)의 값을 전달하는 클래스로 사용될 수 있다.

---

Entity와 DTO 역할 분리의 필요성

1. 유지보수성 유연성

Entity는 데이터베이스와 직접적으로 매핑되는 클래스다. 따라서 데이터베이스 구조가 변경됨에 따라 Entity도 수정을 해주어야 한다. Entity와 DTO를 분리하면, 데이터베이스 구조가 변경되더라도 DTO 구조는 독립적으로 유지할 수 있다. 이로 인해 데이터베이스를 리팩토링할 때 애플리케이션 로직을 변경하지 않아도 되어, 유지보수가 용이하고 유연성을 발휘할 수 있다.

2. 보안

DTO를 사용하는 큰 목적 중 하나는 바로 도메인 모델을 보호하는 것이다. 도메인 모델의 구성 요소인 Entity를 계층간 데이터 전송에 직접 활용하면 당연하게도 데이터베이스 구조가 외부에 직접 노출되어 보안상 위험할 수 있다. DTO를 사용하면 Entity를 계층간의 데이터 전송에 직접 활용하지 않으면서 노출에 민감한 데이터를 제외하고 필요한 데이터만 선택적으로 전달할 수 있어 보안을 한층 더 강화할 수 있다.

3. 성능

Entity 객체는 종종 불필요한 데이터까지 포함하고 있는 경우가 많다. 앞서 말했듯이 DTO는 필요한 데이터만 포함하여 전송할 수 있기 때문에 불필요한 데이터를 줄여 네트워크 성능을 향상시킬 수 있다. 특히 대규모 데이터를 다룰 때 이점이 있다.

4. 검증(Validation) 코드를 모델링 코드와 분리

Entity 클래스에는 Entity간의 관계, 중요한 비즈니스 로직이 작성되어 있는 클래스이다. 여기에 만약 자잘한 검증 코드들이 들어간다면 클래스 내부는 더 복잡해지고 가독성이 저하될 것이다. 따라서 외부에서 받아온 필드에 대한 자잘한 유효성 검증 로직은 DTO 내부에서 처리하는게 된다면 Entity 클래스를 모델링과, 비즈니스 로직에만 집중시킬 수 있다. 참고로 Entity 클래스에서 유효성 검증을 수행하지 못하는 것은 아니다. 중요 비즈니스 로직에 대한 유효성 검증은 Entity 클래스 내부에서 하는 것이 좋다. 

5. 순환참조 예방

JPA에서 양방향으로 참조된 Entity를 Controller에서 반환하면, 순환참조가 발생하게 된다. 이때 DTO를 사용하는 것이 순환참조 방지에 도움이 된다

---

Entity, DTO 변환

Entity

package pack.model;

import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import lombok.Getter;

@Entity
@Getter
public class Player {
	@Id
	private int no;
	private int backnum;
	private String name;
	private int teamno;
	private String position;
	private int pay;
	private String draft;
}

💡 Entity에서의 setter 사용?
"Entity에서의 setter 메소드 사용은 바람직하지 않다. 왜냐하면 변경되지 않는 인스턴스에 대해서도 setter로 접근이 가능하기 때문에 객체의 일관성, 안정성을 보장하기 힘들어진다. 그렇기 때문에 Entity에 setter 대신 Constructor 또는 lombok의 @Builder를 사용하여 불변 객체로 활용할 수있어 데이터를 전달하는 과정에서 데이터가 변조되지 않음을 보장할 수 있다."

DTO

package pack.model;

import lombok.Getter;
import lombok.Setter;

@Getter
@Setter
public class PlayerDto {
	// DTO는 데이터 전달용
	// Entity에서 필요한 데이터만 추출하거나, 전체 데이터를 읽어 또 다른 클래스 혹은 클라이언트에 전달하는 것이 목적이다.
	private int no;
	private int backnum;
	private String name;
	private int teamno;
	private String position;
	private int pay;
	private String draft;
}

Entity > DTO

// Entity를 DTO로 변환하는 방법 1
public static PlayerDto toDto(Player entity) {
	PlayerDto dto = new PlayerDto();
	dto.setNo(entity.getNo());
	dto.setBacknum(entity.getNo());
	dto.setName(entity.getName());
	dto.setTeamno(entity.getTeamno());
	dto.setPosition(entity.getPosition());
	dto.setPay(entity.getPay());
	dto.setDraft(entity.getDraft());
	return dto;
}

// Entity를 DTO로 변환하는 방법 2 (Builder Pattern)
// lombok의 @Builder를 이요하면 쉽게 Builder Pattern을 운영할 수 있다.
// 단계별로 DTO 객체의 각 필드를 선택적으로 설정할 수 있다. 즉, 특정 필드만 골라 데이터를 받을 수 있는 것이다.
public static PlayerDto toDto(Player entity) {
	return PlayerDto.builder()
		.no(entity.getNo())
		.backnum(entity.getBacknum())
		.name(entity.getName())
		.teamno(entity.getTeamno())
		.position(entity.getPosition())
		.pay(entity.getPay())
		.draft(entity.getDraft())
		.build();
}

DTO > Entity

DTO를 Entity로 변환하는 방법 1
public Player toEntity(PlayerDto dto) {
	Player player = new Player(no, backnum, name, teamno, position, pay, draft);
	player.setNo(dto.getNo());
	player.setBacknum(dto.getBacknum());
	player.setName(dto.getName());
	player.setTeamno(dto.getTeamno());
	player.setPosition(dto.getPosition());
	player.setPay(dto.getPay());
	player.setDraft(dto.getDraft());
	return player;
}
	
// DTO를 Entity로 변환하는 방법 2 (Builder Pattern)
public Player toEntity(PlayerDto dto) {
	return Player.builder()
			.no(dto.getNo())
			.backnum(dto.getBacknum())
			.name(dto.getName())
			.teamno(dto.getTeamno())
			.position(dto.getPosition())
			.pay(dto.getPay())
			.draft(dto.getDraft())
			.build();
}

💡 DTO를 Entity로 변환하는 방법 1에 대하여
"위에 언급했듯이 Entity에 setter를 사용하는 것이 썩 좋은 방법이 아니다. 해당 방법은 Entity에 setter가 강요되기 때문에 추천하지 않는다."

toDto()와 toEntity() 메소드 위치

package pack.model;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class PlayerDto {

	private int no;
	private int backnum;
	private String name;
	private int teamno;
	private String position;
	private int pay;
	private String draft;
	
    // Entity > DTO
	public static PlayerDto toDto(Player entity) {
		return PlayerDto.builder()
			.no(entity.getNo())
			.backnum(entity.getBacknum())
			.name(entity.getName())
			.teamno(entity.getTeamno())
			.position(entity.getPosition())
			.pay(entity.getPay())
			.draft(entity.getDraft())
			.build();
	}
}

package pack.model;

import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import lombok.Builder;
import lombok.Getter;

@Entity
@Getter
@Builder
public class Player {
	@Id
	private int no;
	private int backnum;
	private String name;
	private int teamno;
	private String position;
	private int pay;
	private String draft;
	
	public Player toEntity(PlayerDto dto) {
		return Player.builder()
			.no(dto.getNo())
			.backnum(dto.getBacknum())
			.name(dto.getName())
			.teamno(dto.getTeamno())
			.position(dto.getPosition())
			.pay(dto.getPay())
			.draft(dto.getDraft())
			.build();
	}
}

💡 toDto()와 toEntity() 메소드 위치
"toDto() 메소드는 DTO 클래스에 toEntity() 메소드는 Entity 클래스에 구현했지만 두 메소드 모두 DTO에 구현해도 크게 상관은 없는 듯 했다."

Entity와 DTO 변환 위치

package pack.model;

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class PlayerService {
	@Autowired
	private PlayerInterface playerInterface;
	
	// Entity 리스트를 DTO 리스트로 전환
	public List<PlayerDto> getDataAll() {

		// 방법 1
		List<Player> playerList = playerInterface.findAll();
		List<PlayerDto> dtolist = new ArrayList<PlayerDto>();
		for(Player player:playerList) {
			PlayerDto dto = PlayerDto.toDto(player);
			dtolist.add(dto);
		}
		return dtolist; // 반환된 DTO를 리스트로 수집한 후 최종적으로 다시 리스트로 반환한다.

		// 방법 2 (stream + lambda)
		List<Player> playerList = playerInterface.findAll();
			return playerList.stream()
				.map(player -> PlayerDto.toDto(player))
				.collect(Collectors.toList());
		
		// 방법 3 (stream)
		List<Player> playerList = playerInterface.findAll();
			return playerList.stream()
				.map(PlayerDto :: toDto)
				.collect(Collectors.toList());
		// collect : 스트림의 처리 결과를 다시 List 등의 컬렉션으로 변환하는 최종 연산이다. (stream()에서는 중간 연산 안함)
	}
}

💡 Entity와 DTO 변환 위치
"일반적으로 service / controller 두 계층에서 모두 변환 작업이 가능하다. 나는 service에서 변환 작업을 진행하였지만 상황에 따라서 controller에서 변환 작업을 하더라도 큰 문제는 없어 보인다."

Reference

🙏 역할 분리를 위한 Entity, DTO 개념과 차이점

 

🙏 Dto와 Entity를 분리하는 이유, 분리하는 방법

 

🙏 DTO(Data Transfer Object)의 올바른 사용방식에 대해