DAO, DTO, VO, Entity의 개념

1) DAO(Data Access Object)

DAO는 DB의 data에 접근하기 위한 객체로 직접 DB에 접근하여 데이터를 삽입, 삭제, 조회 등 조작할 수 있는 기능을 수행한다.

DataBase 접근을 하기 위한 로직과 비지니스 로직을 분리하기 위해 사용한다.
DAO의 경우는 DB와 연결할 Connection 까지 설정되어 있는 경우가 많다.

현재 많이 쓰이는 Mybatis 등을 사용할 경우 커넥션풀까지 제공되고 있기 때문에 DAO를 별도로 만드는 경우는 드물다.

2) DTO(Data Transfer Object)

DTO는 계층간(Controller, View, Business Layer) 데이터 교환을 위한 자바 빈즈(Java Beans)를 의미한다.

DTO는 로직을 가지지 않는 데이터 객체이고 getter/setter메소드만 가진 클래스를 의미한다.

DTO(Data Transfer Object)는 데이터 전송(이동) 객체라는 의미를 가지고 있다.
DTO는 주로 비동기 처리를 할 때 사용한다.

계층간 데이터 교환을 위한 객체(Java Beans)이다.
DB의 데이터를 Service나 Controller 등으로 보낼 때 사용하는 객체를 말한다.
즉, DB의 데이터가 Presentation Logic Tier로 넘어올때는 DTO로 변환되어 오고가는 것이다.
로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메서드만을 갖는다.
또한 Controller Layer에서 Response DTO 형태로 Client에 전달한다.

Spring Boot DTO 예제 코드

@Getter @Setter
class ArticleDTO {
  private String title;
  private String content;
  private String writer;
}

+) Java Beans

Java로 작성된 소프트웨어 컴포넌트를 지칭하는 단어
비즈니스 로직 부분을 담당하는 Java 프로그램 단위
(장점) JSP페이지가 복잡한 자바 코드로 구성되는 것을 피할 수 있음
(장점) 재사용 가능한 컴포넌트를 만들 수 있음

3) VO(Value Object)

DTO와 달리 VO는 Read-Only속성을 값 오브젝트이다.
자바에서 단순히 값 타입을 표현하기 위해 불변 클래스(Read-Only)를 만들어 사용한다.
예를 들면 빨강은 Color.RED, 초록은 Color.GREEN 이렇게 단순히 값만 표현하기 위해 getter기능만 존재한다.

VO의 핵심 역할은 equals()와 hashcode() 를 오버라이딩 하는 것이다.
VO 내부에 선언된 속성(필드)의 모든 값들이 VO 객체마다 값이 같아야, 똑같은 객체라고 판별한다.

VO는 Getter와 Setter를 가질 수 있으며, VO는 테이블 내에 있는 속성 외에 추가적인 속성을 가질 수 있으며, 여러 테이블(A, B, C)에 대한 공통 속성을 모아서 만든 BaseVO 클래스를 상속받아서 사용할 수 도있습니다.

Spring Boot VO 예제 코드

 

@Getter @Setter
@Alias("article")
class ArticleVO {
private Long id;
private String title;
private String contents;

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Article article = (Article) o;
    return Objects.equals(id, article.id);
}

@Override
public int hashCode() {
    return Objects.hash(id);
	}
}

+) DTO vs VO

DTO는 가변의 성격을 가진 클래스이며 데이터 전송을 위해 존재한다.(getter/setter)
그에 반해 VO는 값 그 자체의 의미를 가진 불변 클래스(Read-Only)를 의미한다.(getter만 존재)

DTO는 인스턴스 개념이라면 VO는 리터럴 개념.
즉, VO는 특정한 비즈니스 값을 담는 객체이고, DTO는 Layer간의 통신 용도로 오고가는 객체를 말한다.

4) Entity 란?

Entity 클래스는 실제 DataBase의 테이블과 1 : 1로 매핑 되는 클래스로, DB의 테이블내에 존재하는 컬럼만을 속성(필드)으로 가져야 한다.
Entity 클래스는 상속을 받거나 구현체여서는 안되며, 테이블내에 존재하지 않는 컬럼을 가져서도 안된다.

Entity 클래스 또는 가장 Core한 클래스라고 부른다.

최대한 외부에서 Entity 클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 method을 구현 해야하고, Domain Logic만 가지며 Presentation Logic을 가지고 있어서는 안된다.

구현 method는 주로 Service Layer에서 사용한다.

1.1 Entity, DTO Class 분리 이유

Entity와 DTO를 분리해서 관리해야 하는 이유는 DB Layer와 View Layer 사이의 역할을 분리 하기 위해서다.

Entity 클래스는 실제 테이블과 매핑되어 만일 변경되게 되면 여러 다른 클래스에 영향을 끼치고, DTO 클래스는 View와 통신하며 자주 변경되므로 분리 해주어야 한다.

결국 DTO는 Domain Model 객체를 그대로 두고, 복사하여 다양한 Presentation Logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용해야한다.

1.2 Entity Setter 금지 및 생성자, 접근 제어

Entity를 작성할 때 setter를 무분별하게 사용하면 객체(Entity)의 값을 변경할 수 있으므로 객체의 일관성을 보장할 수 없다.
객체의 일관성을 유지할 수 있어야 유지 보수성이 올라가기 때문에 setter를 사용해서는 안되며, 객체의 생성자에 값들을 넣어줌으로써 setter 사용을 줄일 수 있다.

// 객체 생성자 설정
@Builder
public Member(String username, String password, String name) {
this.username = username;
this.password = password;
this.name = name;
}

// 객체 생성 시 값 세팅(빌더패턴 사용)
Member member = Member.Builder()
.username("name")
.password("1234")
.name("name)
.build();

아래와 같이 기본 생성자 접근 제한자를 protected로 변경하면 new Member() 사용을 제한해 Entity의 일관성을 더 유지할 수 있다.

// Member 엔티티
@Entity
@Getter
@Table(name = "member")
public class Member{
// 기본 생성자 protected로 접근 제한(기본 생성자 접근 제한자는 protected 까지 허용
//기본 생성자의 접근 제한자를 private으로 걸면, 추후에 Lazy Loading 사용 시 Proxy 관련 예외가 발생)
protected Member(){};

...

}

// @NoArgsconstructor 어노테이션을 통한 protected 접근 제어.
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
@Table(name = "member")
public class Member {

}

 

@Getter
@Setter
@ToString
@Table(name = "user")
@Entity
public class User {
@Id
@GeneratedValue
private int id;

@Column(name = "name", nullable = false)
private String name;

@Column(name = "password", nullable = false)
private String password;

@Column(name = "email", nullable = false, unique = true)
private String email;

@Column(name = "phone", nullable = false, unique = true)
private String phone;

@Column(nullable = true)
private LocalDateTime create_date;

private LocalDateTime modify_date;
}

 

@Entity

테이블과 링크될 클래스임을 나타낸다.
기본값으로 카멜케이스 이름을 언더 스커어 네이밍(_)으로 테이블 이름을 매핑한다.
ex) SalesManager.java -> sales_manager table

@GeneratedValue

PK 생성 규칙
스프링 부트 2.0에서는 GenerationType.IDENTITY 옵션을 추가해야만 auto_increment가 된다.

@Id

해당 테이블의 PK 필드를 나타낸다.

@Column

테이블의 컬럼을 나타내며 굳이 선언하지 않더라고 해당 클래스의 필드는 모두 컬럼이 된다.
사용하는 이유는, 기본값 외에 추가로 변경이 필요한 옵션이 있으면 사용한다.

@Builder

해당 클래스의 빌더 패턴 클래스를 생성
생성자 상단에 선언 시 생성자에 포함된 필드만 빌더에 포함

이 기본적인 걸 왜 다시 정리하는지?

구 어드민 소스에 VO 와 DTO가 뒤죽박죽 사용이 되어있었다.
어디서는 VO를 사용하여 데이터 베이스에 값을 셋팅하는 걸 보고 아 여기는 VO만 사용했나 했는데
DTO도 사용하고 마음대로 규칙없이 사용을 하는 걸 보고 잠시 내가 알고 있는 DTO 와 VO의 개념에 혼란이 왔다.

다시 정리를 하자면
데이터를 셋팅하고 가져오는 용도로는 DTO를 사용하며, getter/setter 메소드 외에 로직은 절대 있으면 안됨!
VO는 데이터를 그대로 가져오는 경우 사용한다. 그래서 데이터 삽입 시, VO를 파라미터로 넣는 거는 이상한거 같다.