코드스테이츠 백엔드 부트캠프 43기 (SpringMVC - Mapper - 서비스 계층)

 

서비스 계층, DTO -> Entity, Mapper

 

지난 시간에는 HTTP 메시지의 내용을 API 계층에서 DTO 객체로 변환하는 내용까지 하였다.

 

오늘 학습한 내용은 

1. 서비스 계층이랑 API 계층 연동 -> DI 방식으로

2. DTO객체를 Entity 객체로 매핑 -> Mapper 를 이용

 

1. 과정을 수행하기 위하여 API 계층에서 서비스 계층의 클래스를 생성하는 것이 아닌 스프링부트에서 지원하는 의존성 주입을 통하여 자동 주입을 해 주었다. 의존성 주입을 위해서 주입할 서비스 계층의 클래스를 @Service 어노테이션을 설정하여 Bean으로 설정해 주었다.

 

 

이제 API 계층인 컨트롤러 클래스에서는 CoffeeService 클래스를 직접 생성하는 것이 아닌 주입을 통하여 느슨해진 결합이 완성 되었다. 생성자를 통하여 매게변수로 서비스계층의 클래스가 주입이 자동으로 된다. (스프링부트의 기능)

(하지만, 생성자가 하나 이상일 경우, DI를 적용하기 위한 생성자에 반드시 @Autowired 애너테이션을 붙여야 한다는 사실을 기억하기 바랍니다)

 

2.이제 DTO 객체를 Entity 객체로 변환하여 서비스 계층에 전달해야 된다.

(DTO 객체를 Entity 객체로 바꾸어서 서비스 계층에 전달하는 이유는 밑에 작성)

API 계층에서 - 컨트롤러 클래스를 통하여 DTO를 생성하여 객체를 만들었고 이제 그 하위단계에서 만든 객체를 요리조리 사용한다. 변환하는 것은 사용자가 일일히 변환 할 수 도 있지만 스프링부트에는 자동으로 변환해주는 기능이 있다.

 

[매퍼(Mapper)를 이용한 DTO 객체 ↔ 엔티티(Entity) 객체 매핑]

 

MapStruct가 매퍼 클래스를 자동으로 구현해줌으로써 개발자의 생산성을 향상 시켜줄 수 있다.

 

 

이런식으로 인터페이스만 설정해준다면 자동으로 인터페이스의 메서드들을 작성해주고 우리는 변경이 필요할때 호출만 해주면 된다.

 

그래서 최종적으로 클라이언트에서 받을 때는 DTO 객체로 받고 밑에서 수행은 DTO 객체를 Entiry 객체로 변환하여 수행하고 변환이 완료된 Entity 객체를 다시 클라이언트로 리턴할 때는 DTO객체로 리턴을 한다.

데이터를 받아와 서비스계층 까지 전달되는 과정

 

(1) 클라이언트가 HTTP 메시지를 서버에 전송 

(2) 메시지의 형식에 맞는 메서드를 찾고 메시지안의 키값에 맞춰 DTO 객체를 생성하여 활용한다.

(3) API 계층이 아닌 다른 계층에서 사용할 때는 DTO 객체를 Entity 객체로 변환한다.

(4) 변환된 Entity 객체를 통해 작업을 수행한다.

(5) 작업이 완료된 Entity 객체는 다시 클라이언트에게 리턴하기 위해 DTO 객체로 변환한다.

(6) 마지막으로 클라이언트에게 DTO 객체를 전달한다.

 

 

---

DTO 클래스와 엔티티 클래스의 역할 분리가 필요한 이유

 

뷰와 통신하는 DTO 클래스는 자주 변경이 되는것을 확인할 수 있다. Entity 는 실제 디비와 매핑이 되는 실제 정보의 객체 그 자체이기에 모든 정보가 포함되어있다. 그렇기에 DTO를 사용하지 않고 Entity만 사용한다면 원하지 않은 정보까지 전달이 될 수 있다. 

 

DTO - 오로지 통신용 서비스 객체

Entity - 실제 DB와 매핑이 되는 객체

 

그렇기에 API 계층에서 데이터를 받을때 유효성 DTO 객체를 통하여 유효성 검사를 하며 유효성 감사는 Entity 객체에는 필요가 없다. - 이러한 기능이 나뉘어져 있기에 Entity 코드는 오로지 객체의 정보만 저장되어 있어 코드 구성이 단순하다.

또한 Entity는 게터메서드로만 구성되어 이씩에  하위계층에서 전달받은 객체가 변경될 위험성이 존재하지 않는다.