vo, dto, Entity

이경현·2025년 2월 4일

1. Entity

  • 실제 데이터베이스 테이블과 메핑되는 핵심 클래스임 데이터베이스 테이블에 존재하는 컬럼들을 필드로 가지는 객체임
  • 영속성을 목적으로 사용되는 객체임
  • 요청이나 응답의 값을 전달하는 클래스로 사용하는건 지양
  • 외부에서 Entity 클래스의 Data Field에 접근하지 못하도록 제한해야 한다
  • id로 구분, 비즈니스 로직(?이 뭔지 모름 일단) 을 포함 할 수 있음
@Entity
@Builder
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class User {
   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   private Long id;
  
   @Column(nullable = false)
   private String name;
  
   @Column(nullable = false)
   private String email;
   
   private String phoneNumber;
}
  • Entity클래스에서는 setter사용을 지양하는 이유: 변경되면 안되는 인스턴스,데이터에 대해 setter로 접근이 가능하다면 객체의 일관성과 안전성을 보장할 수 없기 때문
  • 따라서 Entity 에서는 Constructor 또는 Builder를 사용한다.

2.DTO(Data Transfer Object)

: DTO는 계층간 데이터 교환이 이루어질 수 있도록 하는 객체임

  • 데이터 교환만을 위해 사용함. 비즈니스 로직 X getter/setter메서드만 가진다
  • 컨트롤러같은 클라이언트와 직접 마주하는 계층에서 DTO를 사용하여 데이터를 요청/ 응답을 하고 주로 View와 Controller사이에서 데이터를 주고 받을 때 활용함
@Getter
@Setter
public class MemberDto {
    private String name;
    private int age;
}

3. VO(Value Object)

  • Vo는 값 그자체임
  • getter 메소드는 가질수 있지만, setter 메소드는 가지지 않습니다.(ReadOnly 특징을 가집니다)
  • 비지니스 로직을 포함할 수 있습니다.
@Getter
@AllArgsConstructor
public class UserVo {

    private String name;
    private Integer age;
    private String address;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        UserVo userVo = (UserVo) o;
        return Objects.equals(name, userVo.name) && Objects.equals(age, userVo.age) && Objects.equals(address, userVo.address);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age, address);
    }
}

그래서 이 세가지를 왜 분리해서 사용해 ?

이유1. 관심사의 분리
DTO는 각 계층끼리 주고받는 데이터의 개념
Entity는 데이터의 핵심 비즈니스 로직을 담는 객체
Vo는 값 그자체
이유2. 유효성 검사 로직 및 불필요한 코드 분리하기
이유3. API스팩의 유지
- 만약 Etity 클래스를 통해 API 응답을 한다는 가정하에

- 이런 값이 전달됨

- 이상황에서 갑자기 파람값 이름이라도 바꿔야하면 다른 사용자에게 까지 영향을 주고 수정작업을 해야함

- 그러므로 DTO 를 이용하여 분리해 독립성을 높이고 변경이 전파되는 것을 방지해야 합니다.
  • DTO 를 사용한다면 내부에서 Entity 가 변경되어도 API 스펙이 변경되지 않으므로 안정성을 확보할 수 있습니다.

정리

0개의 댓글