작년에 프로젝트를 하면서 entity를 view에 그대로 반환했다가 Dto로 변환해야겠다는 생각이 들어서 바꿨었는데, Entity와 dto에 대한 내용을 블로그에 정리하면 좋을 거 같아 글을 쓰게 되었다.
(일기 같이 써질 수도 있고, 구글 상단에 노출된 블로그 글을 그대로 가져온 글이 될 수도 있을 것 같지만 프로젝트 기록 하기 위해 작성해보겠다!)

---

⭐ Dto와 Entity를 분리한 이유

entity을 직접 반환하는 코드에서 dto로 변환하여 view한테 반환한 이유는 첫 번째 이유는 Entity의 setter를 없애기 위해서였지만 이와 더불어 내가 찾아본 entity와 dto를 분리해야 하는 이유에 대해 적어보겠다.

☑️ Entity를 보호할 수 있다.

entity를 사용자에게 노출하면 원하지 않는 상황에서 자원의 속성이 변경될 가능성이 있다. 그리고 엔티티를 UI계층에 노출하는 것은 테이블 설계를 화면에 공개하는 것이나 다름없기 때문에 보안상으로도 바람직하지 못한 구조가 된다.
또한 dto는 setter를 허용하지만 entity에서 setter는 무분별하게 사용하면 안된다.

☑️ 화면에 필요한 데이터를 선별할 수 있다.

예를 들어 회원가입을 할 때는 이메일, 비밀번호, 자동로그인 여부 정보만 작성하면 된다. 하지만 도메인 객체 Member는 그 이상의 속성을 가지고 있을 것이다. 필요 이상으로 사용자가 가지고 있는 다른 속성들까지 항상 데이터 전송에 참여하게 되는 것이다. (보안에도 안좋고 속도도 느려짐)
그리고 자동로그인 여부와 같은 속성은 Member에 없을 수도 있다.
이와 같이 Dto와 Entity의 차이로 인해 Dto와 Entity를 분리하는 것이다.

☑️ Entity를 그대로 view에 넘기면, view의 요구사항 변화가 Model에 영향을 끼치기 쉽다.

유저에게 보여줘야 할 정보가 바뀌면, 엔티티를 수정해야 한다.

☑️ 순환참조를 예방할 수 있다.

jpa에서 양방향 참조된 엔티티를 controller에서 반환하면, 순환참조가 발생하게 된다. 결국 무한 루프에 빠져 스택오버 플로우가 발생한다.
jpa에서 순환참조를 해결하려면 @JsonManagedReference와 @JsonBackReference을 사용하거나, @JsonIgnore을 쓰거나 하는 방법도 있지만 Dto를 사용하는 것이 안전기도 하고 개발자가 보기에도 좋기 때문에 많이 추천하고 있다.

☑️ validation 코드와 모델링 코드를 분리할 수 있다.

엔티티 클래스는 DB의 테이블과 매칭되는 필드가 속성으로 선언되어 있고, 복잡한 비즈니스 로직이 작성되어있는 곳이다.
그렇기 때문에, 속성에는 @Column, @JoinColumn , @ManyToOne, @OneToOne 등의 모델링을 위한 코드가 추가된다.

여기에 만약 @NotNull, @NotEmpty, @NotBlank 등과 같은 요청에 대한 값의 validation코드가 들어간다면 엔티티 클래스는 더 복잡해지고 그만큼 가독성이 저하된다.

이때, 각각의 요청에 필요한 validation을 DTO에서 정의한다면, 엔티티 클래스를 좀 더 모델링과, 비즈니스 로직에만 집중되도록 만들 수 있다.

---

⭐ Dto와 Entity 변환 위치에 대한 고민

그럼 Dto와 Entity를 어디서 변환해야 할까?
일단은 (controller-service-repository 계층인 경우) repository에서 dto와 entity을 변환하는 건 아니라는 생각이 들었다. Repository는 Entity의 영속성을 관장하는 역할을 하니까 굳이 찾아보지 않아도 repository에서 변환하는 게 옳지 않다는 생각은 자연스러웠다.

그럼 service vs controller 에 대한 고민을 할 수 있을 것이다.

☑️ Entity -> Dto (응답)

Serice가 entity를 반환하고, Controller가 dto로 변환하는 경우

• View에 반환할 필요가 없는 데이터까지 Domain 객체에 포함되어 Controller(표현 계층)까지 넘어온다.
• Controller가 여러 Domain 객체들의 정보를 조합해서 DTO를 생성해야 하는 경우, 결국 Service(응용 계층) 로직이 Controller에 포함한다.
• 여러 Domain 객체들을 조회해야 하기 때문에 하나의 Controller가 의존하는 Service의 개수가 비대해진다.
  출처 : DTO의 사용 범위에 대하여

이러한 문제점이 있지만, service의 자유도가 높아진다는 장점이 있다.

service가 entity를 dto로 변환해서 controller에게 반환

service에서 entity를 dto로 변환하면, controller는 그 dto 정보를 그대로 view에 보내주면 된다.
'로직'을 service가 수행한다는 점에서 자연스러워 보이기도 하는데
Dto는 view에 의존하고 있는 데이터이다. 그럼 Dto를 service 계층에서 알고있는 것이 바람직한가에 대한 고민이 있을 수 있을 것 같다. 만약 유저에게 보여줄 데이터가 바뀌는 경우가 생긴다면? service 계층까지 코드 수정이 발생한다.
또한 serive에서 view에게 전달할 정보를 모두 알고 있어야 한다.

그리고 나는 view에 entity를 직접 반환하다가 dto를 도입하면서 이런 방식으로 구현했는데,

다른 Service에서 현재 Service를 호출 하고 싶은데 DTO를 반환하니까 문제가 된다

그래서 dto를 도입했을 때 코드를 생각보다 코드를 많이 뜯어고쳤던 것 같다. Serice가 entity를 반환하고, Controller가 dto로 변환하는 경우였다면 이러한 상황이 일어나지 않았을 것이다. (이게 service의 자유도가 높다는 말!)

☑️ Dto -> Entity (요청)

controller가 dto를 entity로 변환해서 service에게 전달

Controller가 View에서 전달받은 DTO만으로 Entity를 구성하기가 어려울 수도 있다.
예를 들면 로그인할 때, LonginDto에는 이메일, 비밀번호 정보만 있는데 이 정보만으로 Member entity 객체를 만들어낼 수 없을 것이다. Member 에는 회원 이름, 회원 id, 비밀번호, 회원 주소, 등급 등 다양한 정보가 있을 것이다.
또한 Dto에는 Entity에 들어가지 않는 정보가 있을 수 있다. (ex. 약관 정보)
따라서 controller가 dto를 entity로 변환하는 건 (service에 의존하게 되므로)
controller에게 버거운 일이 될 수도 있겠다는 생각이 든다.

controller가 Dto를 service에게 전달하고, service에서 entity로 변환하는 경우

service에 Dto가 들어온다는 점에서 약간은 종속적이라고 할 수 있지만, service 함수 상단에서 Dto->Entity 작업을 해주고 그 다음부터는 Dto를 사용하지 않기로 팀원들끼리 약속하면 종속을 최재한 줄일 수 있다.
나는 controller가 dto를 entity로 변환해서 service에게 전달하는 위 방법보다는 이게 더 나은 선택이라는 생각이 든다.

---

나는 처음에 service에서 Dto->Entity, Entity->Dto 작업을 둘 다 해주었다. dto와 entity를 변환한다는 것도 내부 로직에 해당하고 service의 역할과 어울린다고 생각했기 때문이다. 그리고 굳이 entity->dto, dto->entity 이 두 과정을 따로 두지 않는 게 깔끔하다고 생각해서 serive가 두 변환 작업을 하게 만들었다.

(이건 그냥 개인적인 의견입니다)
근데 service에서 Dto를 알고 있다는 게 걸리기도 하고, Dto만으로 entity를 만드는 건 어렵지만 entity를 가지고 dto를 만들어내는 건 service 계층이나 controller 계층이나 비슷할 거라는 생각이 들었다.

그래서 service에서는 바로 dto->entity 해서 이후엔 entity만 사용하고, service는 controller에게 entity를 반환하여 controller가 entity->dto 작업을 수행하게 만들 생각이다.

---

⭐ Dto와 Entity 변환 메서드는 어떻게 구현했는가?

☑️toEntity와 toDto

Member

public MemberDto toMemberDto(){
    MemberDto memberDto = new MemberDto();
    ...
    return memberDto;
}
    }

LoginDto

public Member toEntity(){
    ...
    return new Member(this.getName(), homeAddress, workAddress, this.getEmail(), this.password);
}

난 처음에 Entity에 toDto() 메서드를 만들고, Dto에 toEntity() 메서드를 만들어 변환했다.
근데 Entity가 Dto를 알고있는 게 그렇게 좋게 보이지 않는다. Entity는 핵심 클래스인데 Dto 필드가 변경되면 toDto()라는 메서드도 바껴야 하기 때문에 Entity의 코드 수정이 발생하게 된다.
따라서 Entity가 Dto에 의존하는 것은 좋지 않다.

이건 그냥 간단하게 Dto에서 toDto()와 toEntity()를 둘 다 구현해주는 걸로 해결했다. 처음에 이 방법이 생각 안났던 이유가 이렇게 하면 entity를 dto로 바꿀 때 dto 객체가 있어야 바꿀 수 있는 거 아닌가..? 그럼 이미 dto가 있는데 왜 바꾸지? 라는 생각 때문이였다.
결론적으론 정적메서드로 만들어서 객체 없이 쓸 수 있게 하여 Dto 안에 두 함수를 다 넣을 수 있었다.

☑️ builder 패턴과 정적팩토리메서드

이펙티브 자바 아이템1, 아이템2를 읽으면서 기존 생성자로 객체를 만들어주는 방식이 아닌 Builder로 객체를 생성하는 방식으로 바꿨다.

그리고 위에도 써놨지만 Dto안에 entity->dto, dto->entity 함수를 둘 다 넣으면서 정적메서드로 바꾸었는데, 바꾸면서 toDto라는 메서드명보다 정적팩토리메서드 네이밍 컨벤션을 지켜 from이나 of이라는 이름이 적합하다고 판단하여 수정하였다.

---

참고했던 글들
[DTO] DTO의 사용범위에 대하여
DTO의 사용 범위에 대하여
Service에서 DTO를 반환해도 괜찮을까?
요청과 응답으로 엔티티(Entity) 대신 DTO를 사용하자