[MVC] DTO 역할 구분, 프로젝트 흐름도 분석

서론

이전에 Entity와 Dto를 분리하고 사용하는 방법에 대해 확인해 보았다.

이후, Dto를 활용하는데 Dto는 역할과 책임을 명확히 하기 위해

requestDto와 responseDto로 나눌 수 있다는 사실을 알게 되었다.

 

여기서 Dto는 어디서 Entity가 치환이 되는 것이며, 어디서 반환되는 것일까?

 

이번 포스팅에는 DTO의 역할을 정리하고,

Dto와 Entity가 사용되는 부분을 데이터 흐름도를 그려서 확인해 보며 정리하는 시간을 가지려고 한다.

 

Dto의 역할

Dto (Data Transfer Object) 클래스는 주로 데이터 전송에 사용되는 객체이다.

보통 데이터베이스의 엔티티와 1:1로 매핑되는 경우가 많은데,

이 경우 DTO 클래스는 엔티티의 필드와 유사한 구조이다.

 

하지만 엔티티와 DTO 클래스는 각각의 역할과 책임이 있다.
엔티티는 데이터베이스에 저장되고 관리되는 데이터를 나타내는 반면,
DTO 클래스는 비즈니스 로직에서 사용되는 데이터 전송 객체이다.

 

 DTO 클래스에서도 Request와 Response로 구분하는 이유는 다음과 같다.

<requestDTO를 사용하는 이유>

1. @RequestParam으로 데이터를 일일이 받을 필요 없이 객체 하나로 한꺼번에 받을 수 있다.

2. Bean Validation, Contoller에서 검증 기능을 분리할 수 있다.

3. 엔티티 내부를 캡슐화할 수 있다. (엔티티의 값이 변경되지 않도록 한다)

 

<responseDTO를 사용하는 이유>

1. 넘겨줄 필요가 없는 데이터를 보내지 않을 수 있다. (화면에 꼭 필요한 데이터만 보내줄 수 있다)

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

3. 엔티티 내부를 캡슐화할 수 있다.

 

이와 같이 Dto 클래스를 구분함으로써 코드의 가독성과 유지보수성을 높일 수 있다.

프로젝트의 흐름과 관련된 코드 부분의 다이어그램을 살펴보며 Dto와 Entity가 사용되는 시점도 확인해 보자.

프로젝트 흐름도 분석

다음은 프로젝트 흐름과 관련된 코드 부분의 다이어그램이다. 

 

이와 같이 Request DTO 클래스는 클라이언트로부터 전달받은 요청 데이터를 담고 있는 객체이며,
컨트롤러에서 사용되어 비즈니스 로직에서 필요한 데이터를 추출하여 서비스나 DAO에 전달하는 용도로 사용된다.

Response DTO 클래스는 비즈니스 로직에서 생성된 데이터를 클라이언트에 반환하기 위한 객체이며, 컨트롤러에서 생성되어 클라이언트에 반환된다.
Response DTO 클래스는 클라이언트가 필요로 하는 최소한의 정보만을 전달하기 위해 사용된다.

불필요한 데이터를 제외하고 필요한 데이터만을 포함시키기 때문에, 클라이언트의 성능과 응답 시간을 개선할 수 있다.

 

또한, Service 계층에 Entity를  사용하면, 엔티티에만 의존하기 때문에 서비스 계층의 재사용성이 높아진다.

 

설계 후 프로젝트를 진행하면 Service 계층에서 담당하는 부분이 늘어나는 것이 사실이다. 그렇기에 이 부분을 잘 해결하지 않으면 많은 로직을 담당하는 service를 만들어진다.

실제로 이전 프로젝트에서 Service에 담당하는 로직이 너무 많아 가독성이 너무 떨어졌다.

 

그렇기에 서비스 계층에서도 핵심 비즈니스 로직을 가지고 있는 서비스 로직과, 화면에 맞춘 읽기 전용 서비스 로직을 별도로 분리해서 설계하는 것도 좋은 설계일 것 같다.