오늘도 내용과 상관없는 제목이다.
늘 블로그 글을 쓰기로 해놓고 매일 하루하루 밀려서 오늘은 꼭 쓰겠다는 마음 다짐으로 제목을 정하고 글을 써보기로 했다.
오늘은 크게 DTO라는 주제에 대해 학습을 진행했다. 여기서 DTO란 무엇이길래 하루종일 얘를 가지고 학습을 할까??
DTO(Data Transfer Object)
DTO는 말 그대로 데이터의 전송용 객체 라고 직역할 수 있다.
쉽게 말하자면 로직을 위해 필요한 data들만 담아서 그때마다 형태를 바꾼다고 나는 이해하였다.
자연스럽게 DTO는 기존의 Entity(data)의 사본이 되며 사용자가 원하는 식으로 만들어 처리할 수 있다.
그럼 기존의 data를 어떤식으로 만들어서 사용할까??
builder를 통해 만들기
우선 가장 간단하게 builder를 사용하여 원하는 data만 뽑아 새로운 Dto객체로 생성해 줄 수 있다.
두번째 방법으로 생성자를 통해 만드는 방법도 있지만 인자의 수가 많아 질 경우 생성자의 변수 순서나 타입때문에 번거로운 경우가 많으니 위의 사진처럼 쉽게 판단할 수 있는 builder를 사용하여 Dto를 만들었다.
이렇게 만든 Dto는 근본적으로 하나의 객체,데이터가 Repository까지 들어가면 왜 안될까 라는 물음에서 만들어지게 되었는데
나는 이 질문에 대해 클라이언트 단에서 입력을 받는 형식이 바뀌었고 이를 DB로 넣는 과정은 그대로 라면 그냥 객체를 사용했을 때에는 입력과정에서 오류가 발생하지만 DTO를 통한 처리 후 객체를 전달 할 경우에는 오류가 발생하지 않는다고 생각했다. (사실 아직도 생각이 잘 정리되지는 않아 계속 생각해볼 것 같다.)
추가적으로 다같이 생각해 본 이유에는
클라이언트가 필요 없는 데이터 포함 - System column - createdAt, updatedAt 과 같이 client는 전혀 사용할 일이 없는 컬럼 들 (시스템 활용 데이터 ,생성/수정 일시)
클라이언트가 필요한 데이터 미 포함 - 구현 코드 연관 관계 x →화면에는 같이 뿌려져야 하는 거, DB엔 생년월일이 있고 나이를 뽑아야 할 때. (연산이 필요할 때)
스프링 3계층(C/S/R) 간의 전송(이동) 시 데이터 변환 위험
이라는 3가지의 이유가 있었다.
비슷한 느낌으로 data를 옮기는 객체가 하나 일 경우 여러 계층에서 그 객체에 수정을 가하면 단일 책임 원칙이 바로 깨진다.라는 단일 책임 원칙에 관한 이유도 있었는 데, 이 말이 가장 와닿았다.
DTO사용
실제로는 RequestDto와 ResponseDto 2개를 나누어 구성하고 사용할 때에도 다르게 사용해야 하지만 생각없이 코드를 짜다보니 이렇게 되고 말았다.
그림처럼 나는 service단에서 Dto를 사용하여 data의 모양을 바꾸었다.
데이터를 변환하는 이유가 데이터가 전달 되는 과정에서 불필요한 data의 존재를 지우고 보안을 높이기 위해서라고 생각했기 때문이다.
Client→Controller→Service→Repository→DB
DB→Repository→Service→Controller→Client
실질 적으로는 위의 데이터가 전달되는 과정에서 개발하는 사람과 맞춰서 통일만 한다면 어디든지 사용해도 가능하다. (대신 명확한 이유를 가지고 있다면)
나는 이떄까지 DTO를 사용자에게 보여줘서는 안되는 data를 관리하기 위해서 사용하고 간단하게 이해하고 사용하였었는데 DTO는 어떠한 비지니스로직을 가지지않는 순수한 data의 저장객체이고, 이를 통해 모델과 뷰의 결합성을 느슨하게 만들 수 있는 수단이라는 것을 알게 되었다.
이렇게 점차 학습을 통해 왜 이 기술과 방식을 사용하는지 학습하여 3주밖에 남지 않은 백엔드 프로젝트에서는 완벽하지는 않아도 왜 그렇게 설계하고 코드를 작성했는지 설명할 수 있는 프로젝트를 진행하고 싶다.
열심히 생각하고 코드 짜자
이름 정하는 건 어렵죠