DTO와 Entity 간의 변환
DTO -> Entity 혹은 Entity -> DTO의 변환과정은 어떻게 될까. 많이 사용하는 방법은 두 가지이다.
1. controller에서 변환
-> controller와 domain이 결합하여 domain을 변경하면 controller도 연쇄적으로 변경해야할 수도 있음
2. service에서 변환
-> controller와 service의 결합도 높아짐
3. Mapper
-> controller와 service 사이에 위치하여 사이에서 변환을 담당
DTO design
1. 필요에 따라 구성
RequestDTO
클라이언트로부터 전달받은 요청 데이터를 담은 객체
@RequestParam으로 데이터를 하나씩 받을 필요없이 객체로 한 번에 받을 수 있음
엔티티 캡슐화 -> 엔티티의 값이 변경되지 않도록 함
ResponseDTO
비즈니스 로직에서 생성된 데이터를 클라이언트에 반환하기 위한 객체 (컨트롤러에서 생성되어 클라이언트에 반환)
꼭 필요로하는 데이터만 넘길 수 있음
엔티티 캡슐화
클래스 작성 할 때, 화면에 필수적으로 보여져야하는 데이터가 뭔지 생각해보면 좀 명쾌할지도
단점:
하지만 단순히 DTO 패키지에 필요할 때마다 새로운 class를 생성하면 파일이 너무 많아진다
-> 알아보기 힘들다. 이에 대한 해결책을 아래에 기술한다.
2. Inner class 혹은 Nested class
장점:
깔끔한 패키지
DTO className정하기 수월해짐
inner class에 static을 붙이는 이유
static이 붙지않은 inner class는 같은 상위 클래스에 포함되어있는 다른 inner class에 접근이 가능하다. 해당 클래스가 private이어도 가능하다.
반면 static이 붙은 inner class는 다른 클래스의 멤버에 접근할 수 없다. (outer class들에는 가능)
단점:
클래스의 개수는 줄어들었겠지만 새로운 클래스가 필요할 때마다 재생성 해야함
DTO 재사용 불가
참고
1. https://velog.io/@jihoon-gh/Dto%EC%99%80-Entity%EC%9D%98-%EB%B3%80%ED%99%98%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EB%AF%BC%EA%B3%BC-Mapper%EC%9D%98-%EC%82%AC%EC%9A%A9
2. https://lackofwillpower.tistory.com/166
3.
