TO/VO Pattern

1. 정의

이슈에서 언급된 것처럼, TO는 Transfer Object 패턴을 의미하고, 함께 언급이 되는 VO는 Value Object 패턴을 의미한다. 이름에서 유추할 수 있듯이 해당 패턴들은 데이터를 전송하기 위한 디자인 패턴이다.

2. VO 패턴

사실, VO 패턴은 변경 불가능한 객체를 나타내는데 사용되는 객체 생성 디자인 패턴이다. 일반적으로 자주 변경되지 않고 단일 단위로 전달될 수 있는 데이터를 나타내는데 사용된다. 날짜,통화,수량 등을 나타낼 때 사용할 수 있다. 조금 더 개발적으로 이야기하면, Client에서 보내는 Request 는 백엔드에서 변경할 일이 없으므로 이를 VO로 받을 수 있다.

하지만, 실제로는 명확한 구분도 없고 엄격하게 나누지도 않는다. 개발자마다 객체를 구분하고 정의하는 스타일이 달라서 DB에서 데이터를 꺼내올 때 DTO를 쓰는 경우도 있고, VO를 쓰는 경우도 있다. 또, VO를 불변으로 쓰지 않는 경우도 많다.

그래서 아래 내용에서는, TO 패턴을 기준으로 설명하고자 한다.

3. 패턴 사용 목적

Transfer Object 를 만들어 하나의 객체를 통해 여러 타입의 값을 전달하는 것이 TO 패턴의 목적이다. 이를 사용한다고 엄청난 성능 개선 효과가 발생하는 것은 아니지만, 한 객체에 결과 값을 가져올 수 있기 때문에 여러 번 요청을 줄여주므로 해당 패턴 사용이 권장된다.

또한, 속성 값이 null 인 경우 길이가 0인 String을 return 하는 등 Transfer Object 를 null 처리 과정을 편하게 할 때도 사용할 수 있다.

4. DTO Class

DTO는 Data Transfer Object의 줄임말로, 계층간 데이터 전송을 위한 JavaBeans을 의미한다. DAO(Data Access Object) 패턴에서 유래된 단어로, DAO에서 DB 처리 로직을 숨기고 DTO 라는 결과값을 내보내는 용도로 활용된다.

비즈니스 로직은 가지지 않고, 데이터를 전송하는데 필요한 getter 와 setter 메소드만 가지는 단순한 객체이다.
Controller 같은 클라이언트단과 직접 마주하는 계층에서는 DTO를 사용해서 데이터를 교환하며, Controller 외에도 여러 레이어 사이에서 DTO를 사용할 수 있다. 그치만 주로 View와 Controller 사이에서 데이터를 주고 받을 때 활용성이 높다.

추가로, DTO는 JSON serialization 과 같은 직렬화에도 사용된다.

5. 실제 사용 예시

public class GillogTO implements Serializable {

    private String name;
    private String id;

    public GillogTO() {
        super();
    }
    public GillogTO(String name, String id) {
        super();
        this.name = name;
        this.id = id;
    }
    public String getName() { return name;}
    public String getID() { return id; }

    public void setName(String name) { this.name = name;}

    public void setID(String id) { this.id = id;}

    public String toString() {
        StringBuilder sb = new StringBuilder();
        sb.append("name=")
            .append(name)
            .append("id=")
            .append(id)
        return sb.toString();
    }
}

@Getter
@NoArgsConstructor
public class PostssaveRequestDto{
    private String title;
    private String content;
    private String author;

    @Builder
    public PostsSaveRequestDto(String title,String content,Strign author) {
        this.title = title;
        this.content = content;
        this.author = author;
    }
    public Posts toEntity() {
        return Posts.builder().title(title).content(content).author(author).build();
    }
}

7. Entity Class

Entity 클래스는 실제 DB 테이블과 매핑되는 핵심 클래스로, DB 컬럼들을 필드로 가지는 객체이다. 데이터베이스 영속성 의 목적으로 사용되는 객체기 때문에, 요청이나 응답값을 전달하는 클래스로 사용하는 것은 좋지 않다. 또한, 많은 서비스 클래스와 비즈니스 로직들이 Entity 클래스를 기준으로 동작하기 때문에 Entity 클래스가 변경되면 여러 클래스에 영향을 줄 수도 있다.

⁉ DTO 클래스와 분리하는 이유

1. Entity 클래스가 DB와 맞닿은 핵심 클래스이기 때문에

Entity 클래스를 기준으로 테이블이 생성되고 스키마가 변경되는데, 화면 변경 등의 사소한 기능 변경을 위해 테이블과 연결된 Entity 클래스를 변경하는 것은 너무나 큰 변경이 된다.

또한, View Layer 와 DB Layer 의 역할을 철저하게 분리하는 것이 좋다. 하지만 실제로는 Controller에서 결과값으로 여러 테이블을 조인해서 줘야하는 경우가 빈번하므로 Entity 클래스만으로 표현하기 어려운 경우가 많다.

2. 다양한 비즈니스 로직과 요구사항에 유연하게 대응하기 위해서

파라미터로 Entity 자체를 받게 되면, Entity에서 정해진 포맷에 맞춰 개발해야 한다. 하지만, DTO는 각 비즈니스 로직에 맞춘 필드들만 생성이 가능하므로 DTO를 보면 어떤 값들이 매핑되는지 쉽게 파악할 수 있다. 또한, API 설계 상황에서 필드에 다른 이름을 부여하는 상황에도 유연하게 대처할 수 있다.

3. Controller와 Service 사이에서 강한 의존을 방지하기 위해서

Service가 받고 싶은 파라미터가 Controller에게 종속적이면 Service가 Controller 패키지에게 의존하게 된다. 이를 방지하기 위해서 Service가 원하는 포맷에 맞춰 Controller단에서 DTO를 통해 포맷을 맞춰주는 것이다.

4. Service Layer가 모듈로 분리되어 버리면 해당 Type을 쓸 수 없기 때문에

5. 트랜잭션으로 처리되어야 하는 DTO 항목이 항상 요청으로 들어온 결과값과 동일하지 않을 수 있기 때문에

사용자 요청의 파라미터를 통해 외부 API를 여러 번 호출하고 Service 레이어를 호출하면?
- Controller가 받은 Web DTO 와 Service가 받아야 할 DTO가 달라짐
외부 API 호출뿐만 아니라, Client 요청 이후 Service레이어를 호출하기 전 다른 작업으로도 데이터 포맷이 달라질 수 있음

위와 같은 경우, Service 레이어가 Controller 레이어 DTO에 의존하고 있다면 문제가 될 수 있다. 따라서, Service 레이어는 자신이 원하는 포맷으로 데이터를 받을 수 있어야 한다.

+ Entity 클래스 참고 사항

Entity에서는 객체의 일관성, 안전성을 보장하기 위해 setter 메서드의 사용을 지양해야 한다. 따라서, setter 대신 Constructor 또는 Builder 를 사용해야한다.

Constructor 를 이용해서 초기화하는 경우, 불변 객체로 활용할 수 있고, 불변 객체로 만들면 데이터를 전달하는 과정에서 데이터가 변조되지 않음을 보장할 수 있다.

Builder 를 사용하면, 멤버 변수가 많아지더라도 어떤 값을 어떤 필드를 넣는지 코드를 통해 확인이 가능하다. 또한, 필요한 값만 넣는 것이 가능하다는 것도 장점이다.

@Builder  
@Getter  
@Entity  
@NoArgsConstructor  
public  class Membmer { @Id  @GeneratedValue(strategy = GenerationType.IDENTITY)  
private Long idx; 
private String name; 
private String email; 
public Member(Long idx, String name, String email) { 
        this.idx = idx; 
        this.name = name; 
        this.email = email; 
    } 
} 
// 사용 방법 
Member member = Member.builder() 
.name("Jan") 
.email("Jan@Jan.com") 
.build();

참고자료

https://akku-dev.tistory.com/26 https://velog.io/@gillog/Transfer-Object-Pattern https://wildeveloperetrain.tistory.com/m/101 https://wildeveloperetrain.tistory.com/101 https://velog.io/@pjy05200/DTO%EC%99%80-Entity-Class%EC%9D%98-%EC%B0%A8%EC%9D%B4 https://studyandwrite.tistory.com/402

SSARTEL-10th / JPTS_bookstudy

TO.. VO..? #26

👍 문제

✈️ 선정 배경

📺 관련 챕터 및 레퍼런스

🐳 비고