개요
Entity와 DTO의 차이가 무엇이고, 분리해야 하는 이유에 대해 정리해 보고자 한다.
Entity
Entity는 데티어베이스의 테이블과 직접적으로 매핑되는 클래스이다. 주로 ORM(Object-Relational Mapping) 프레임워크를 통해 사용되며, Java에서는 JPA(Java Persistence API)가 널리 사용된다. Entity는 데이터베이스의 상태를 반영하고, 영속성(Persistence)을 가지고 있다.
예시
@Entity
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String username;
private String password;
private String email;
// Getters and setters
}DTO(Data Transfer Object)
DTO는 데이터 전송을 목적으로 사용하는 객체이다. 주로 네트워크를 통해 데이터를 전송할 때, 또는 레이어 간의 데이터 교환을 위해 사용된다. DTO는 데이터베이스와 직접적인 연관이 없으며, 영속성을 가지지 않는다.
예시
public class UserDTO {
private Long id;
private String username;
private String email;
// Getters and setters
}Entity와 DTO의 주요 차이점
목적
- Entity: 데이터베이스 테이블과 매핑되어 데이터의 영속성을 관리한다.
- DTO: 데이터를 전송하는 데 사용되며, 영속성을 가지지 않는다.
구조와 필드
- Entity: 데이터베이스 구조를 반영하며, 복잡한 관계 및 비즈니스 로직을 포함할 수 있다.
- DTO: 간단하고, 필요한 최소한의 데이터만 포함한다.
영속성
- Entity: 영속성 컨텍스트에 의해 관리되며, 데이터베이스에 저장된다.
- DTO: 영속성을 가지지 않으며, 일시적으로 데이터를 담아 전송한다.
사용 시점
- Entity: 데이터베이스 연산(CRUD)을 수행할 때 사용된다.
- DTO: 클라이언트와의 데이터 교환, API 응답 등에서 사용된다.
Entity와 DTO를 분리하는 이유
Entity와 DTO를 분리하는 이유는 다음과 같은 이유들이 있다:
관심사의 분리
- 관심사의 분리를 통해 코드의 가독성과 유지보수성을 높일 수 있다.
- Entity는 데이터베이스 테이블과 직접적으로 매핑되어, 데이터베이스 연산과 비즈니스 로직을 포함합니다. 이는 영속성 계층의 일부로서, 데이터베이스와의 상호작용을 관리한다.
- DTO는 데이터를 전송하기 위한 객체로, 주로 서비스 계층과 표현 계층 간의 데이터 교환을 위해 사용됩니다. 이는 필요한 데이터만 포함하여, 클라이언트에 데이터를 전달하거나 API 응답을 구성하는 데 사용된다.
- 이러한 분리는 코드의 가독성과 유지보수성을 높여준다.
보안성 향상
- Entity 객체를 직접 클라이언트에 노출시키면 민감한 데이터가 외부로 유출될 위험이 있기 때문에 DTO를 사용하여 클라이언트에 필요한 정보만 선택적으로 제공할 수 있다.
// Entity에 비밀번호와 같은 민감한 정보 포함
@Entity
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String username;
private String password; // 민감한 정보
private String email;
// Getters and setters
}
// DTO에는 민감한 정보 제외
public class UserDTO {
private Long id;
private String username;
private String email;
// Getters and setters
}
성능 최적화
- Entity 객체는 많은 필드와 복잡한 관계를 가지고 있다. 이러한 데이터를 그대로 전송 하면 성능 저하를 초래할 수 있다. 따라서 DTO를 사용하여 필요한 필드만 포함하여 데이터 전송을 최적화할 수 있다.
// Entity의 모든 필드 전송 시 성능 저하 가능성
@Entity
public class Product {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String name;
private String description;
private BigDecimal price;
private LocalDateTime createdDate;
// Getters and setters
}
// DTO를 통해 필요한 필드만 전송
public class ProductDTO {
private Long id;
private String name;
private BigDecimal price;
// Getters and setters
}유지보수 및 확장성
- Entity와 DTO를 분리하면 코드의 유지보수성과 확장성이 크게 향상된다. 데이터베이스 스키마나 비즈니스 로직이 변경될 때에는 Entity만 수정하면 되고, API나 클라이언트와의 데이터 교환 형식이 변경될 때는 DTO만 수정하면 된다.
순환 참조 예방
- 순환 참조는 두 객체가 서로를 참조하는 경우 발생하며, 이는 시스템의 안정성을 저해하고 디버깅을 어렵게 만든다. 예를 들어, A 객체가 B 객체를 참조하고, B 객체가 다시 A 객체를 참조하는 상황이 발생할 수 있다. 이렇게 되면 직렬화(Serialization)나 역직렬화(Deserialization) 과정에서 스택 오버플로(Stack Overflow)와 같은 문제가 발생할 수 있다.
- DTO를 사용하면 데이터 전송 계층에서 순환 참조가 발생하지 않도록 구조를 단순화할 수 있다. DTO는 필요한 데이터만 포함하므로 순환 참조의 위험을 줄여준다.
검증(validation) 로직과 모델링 코드의 분리
- Entity는 주로 데이터베이스 테이블과 직접 매핑되는 도메인 모델이다. 이 모델에는 비즈니스 로직과 데이터베이스와의 상호작용을 처리하는 코드가 포함되어 있다.
따라서 Entity 클래스에 @NotNull, @NotEmpty과 같은 Validation 코드가 추가되면 코드가 복잡해지고 가독성이 저하된다. - 반면, DTO는 주로 클라이언트와의 데이터 교환을 위해 사용된다. DTO를 사용하면 입력 데이터에 대한 검증(validation) 로직을 엔티티와 분리할 수 있다. 이렇게 하면 엔티티는 순수하게 데이터베이스와의 상호작용에 집중할 수 있고, 검증 로직은 DTO에서 처리되어 코드의 응집도가 높아진다.
Model에 영향을 미치는 View의 요구사항 변화
- 웹 애플리케이션에서 뷰(view) 계층은 사용자 인터페이스(UI)와 직접 상호작용한다. 뷰의 요구사항이 변경될 때마다 모델(Entity)을 수정해야 한다면, 이는 전체 시스템에 큰 영향을 미칠 수 있다. 모델은 데이터베이스 구조와 밀접하게 연결되어 있기 때문에, 모델의 변경은 데이터베이스 스키마의 변경을 유발할 수 있으며, 이는 상당한 위험과 비용을 동반한다.
- DTO를 사용하면 이러한 문제를 해결할 수 있다. 뷰 요구사항 변화에 따라 DTO를 수정하고, 필요시 엔티티와 DTO 간의 매핑 로직만 수정하면 된다. 이를 통해 모델의 안정성을 유지하면서도 뷰 계층의 변화에 유연하게 대응할 수 있다.
결론
Entity와 DTO는 각각 다른 목적을 가지고 있으며, 그 목적에 맞게 사용해야 한다. Entity는 데이터베이스와의 상호작용을 관리하고, DTO는 데이터를 전송하는 데 최적화되어 있다. 이 둘을 적절히 사용하면 소프트웨어의 유지보수성과 성능을 향상시킬 수 있다.
참조
안녕하세요 백엔드 개발자입니다.