1. Entity란?
Entity 클래스는 실제 DataBase의 테이블과 1 : 1로 매핑 되는 클래스로, DB의 테이블내에 존재하는 컬럼만을 속성(필드)으로 가져야 한다.
Entity 클래스는 상속을 받거나 구현체여서는 안되며, 테이블내에 존재하지 않는 컬럼을 가져서도 안된다.
@Entity는 JPA의 어노테이션이며, 실제 DB의 테이블과 매칭되는 클래스에 붙인다. JPA를 사용하면 DB 데이터에 작업할 경우 실제 쿼리를 날리기보다는, 이 Entity 클래스의 수정을 통해 작업한다. Entity 클래스의 예시는 다음과 같다.
package com.spring.project.domain.posts;
import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;
import javax.persistence.*;
@Getter
@NoArgsConstructor
@Entity
public class Posts {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(length = 500, nullable = false)
private String title;
@Column(columnDefinition = "text", nullable = false)
private String content;
private String author;
@Builder
public Posts(String title, String content, String author) {
this.title = title;
this.content = content;
this.author = author;
}
}
- @Id : 해당 테이블의 PK 필드를 나타냄
- @GenereatedValue : PK의 생성 규칙을 나타내고, GenerationType.IDENTITY 옵션을 추가해야 auto_increment됨
- @Column : 테이블의 칼럼을 나타냄
- @NoArgsConstructor : 기본 생성자 자동 추가, public Posts () {}와 같은 효과
- @Getter : 클래스 내 모든 필드의 Getter 메소드를 자동생성
- @Builder : 해당 클래스의 빌더 패턴 클래스를 생성, 생성자 상단에 선언 시 생성자에 포함된 필드만 빌더에 포함
Entity 클래스에서는 절대 Setter 메소드를 만들지 않는다. 대신, 명확히 그 목적과 의도를 나타낼 수 있는 메소드를 만든다.
예시코드는 다음과 같다.
public class order{
public void cancelOrder(){
this.status = false;
}
}
public void 취소(){
order.cancelOrder();
}
그럼 Setter가 없는 상황에서 어떻게 값을 채워 DB에 삽입해야 할까?
기본적인 구조는 생성자를 통해 최종값을 채우고, 값 변경이 필요한 경우 해당 이벤트에 맞는 public 메소드를 호출한다.
또한 @Builder를 통해 제공되는 빌더 클래스를 사용한다. 둘 다 생성 시점에 값을 채워주는 역할은 같다. 빌더를 사용하게 되면 어느 필드에 어떤 값을 채워야 할지 명확하게 인지할 수 있다.
예시코드는 다음과 같다.
// 생성자를 통한 값 삽입
public Example(String a, String b){
this.a = a;
this.b = b;
}
// 빌더를 통한 값 삽입
Example.builder().a(a).b(b).build();
Entity 클래스와 기본 Entity Repository는 함께 위치해야 한다.
2. DTO란?
계층간 데이터 교환을 위한 객체(Java Beans)이다.
DB의 데이터를 Service나 Controller 등으로 보낼 때 사용하는 객체를 말한다.
즉, DB의 데이터가 Presentation Logic Tier로 넘어올때는 DTO로 변환되어 오고가는 것이다.
로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메서드만을 갖는다.
또한 Controller Layer에서 Response DTO 형태로 Client에 전달한다.
DTO와 Entity를 왜 분리해야 되는가?
Entity와 DTO를 분리해서 관리해야 하는 이유는 DB Layer와 View Layer 사이의 역할을 분리 하기 위해서다.
Entity 클래스는 실제 테이블과 매핑되어 만일 변경되게 되면 여러 다른 클래스에 영향을 끼치고, DTO 클래스는 View와 통신하며 자주 변경되므로 분리 해주어야 한다.
결국 DTO는 Domain Model 객체를 그대로 두고, 복사하여 다양한 Presentation Logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용해야한다. 절대로 Entity 클래스를 Request/Response 클래스로 사용해서는 안된다.
'Computer Science > 디자인 패턴' 카테고리의 다른 글
MVC 패턴에 관한 고찰 (0) | 2022.12.02 |
---|---|
@Transactional에 대해 알아보자 (0) | 2021.11.29 |
DI(Dependency Injection)이란? (0) | 2021.11.27 |