학습계기
공부를 하던 중, 본격적으로 JPA를 활용한 개발은 Entity를 만들고 dto와 구분하여 진행하였다. 기존의 mybatis 때는 dto 만 활용해서 개발을 진행하였었는데 각각의 차이점과 dto, entity 외 model의 개념도 알아보고 추후 활용 가능한 영역에서 활용해보려 한다.
출처 : https://hudi.blog/data-transfer-object/
DTO vs Model vs Entity
DTO : 클라이언트의 데이터를 받는 역할, 클라이언트에서 사용하는 것으로 노출되도 상관 없는 것
Model : 비즈니스 데이터를 담는 역할
Entity : DB의 테이블과 스키마를 표현하는 역할, DB 컬럼과 연결되기 때문에 필드명 노출되면 안됨
DTO는 클라이언트 단에서도 확인 가능하다, object를 보내면 어떤 것들이 들어와있는지 확인 가능하기 때문이다. 하지만 entity의 정보가 노출이 될 시 DB를 탈취하려는 시도들이 발생할 수 있기 때문에 entity의 노출 (DB 정보의 노출) 은 최대한 지양되어야 한다(캡슐화).
그렇다면 model는 어떻게 쓰일까?
명확한 답은 아니지만 컨벤션에 따라 유연하게 쓰이는 것 같다. DTO를 그대로 쓰기도 하는 때가 있고 모델을 따로 만들어서 사용하는 경우도 있다. 각각 상위 레이어 (레이어드 아키텍쳐 패턴의 경우)에 보내줄 정보들을 담고만 있으면 될 것 같다.
아키텍처
Request → Controller(프레젠테이션 레이어, DTO) → Service(비즈니스 레이어, Model) → Persistence(퍼시스턴스 레이어, Entity) → DB(데이터베이스 레이어) → Persistence(entity) → Service(model) → Controller (DTO)→ Response
위의 흐름으로 이동한다고 보면 될 것 같다.
Request와 Response의 분리
Request와 Response의 분리의 필요성을 느끼고 있다.
Request는 받아오는 정보들 => 클라이언트에서 받는 정보들
Response는 뿌려줄 정보들 => 클라이언트에게 줄 정보들
이렇게만 하면 어? 똑같이 쓰면 되는거 아니야? 라고 생각 할 수 있다.
처음에 프로젝트 할 때는 똑같은 구성으로 하나의 DTO만 관리하였었다.
하지만 RequestDTO 를 받은 뒤, Entity로 변환하고 그 정보를 Validation 하는 과정에서 오류가 발생했을 경우, 오류 메시지를 보낸다고 하였을 때, 기존 RequestDTO에 오류메시지를 넣어서 관리하는 것은 비효율적인 코드가 되고 관리하기에도 어려움이 따른다.
따라서 ResponseDTO를 만들어 오류메시지를 담을 수 있는 필드를 만들어주어 리턴해주는 것이 바람직한 것이다.
회고
Entity에 대해서 흐름을 파악하지 못하고 독립적으로 생각하였던 부분들이 있었다. 가령 JPA 를 할 때만 쓴다든지 하는 것과 같이 일정 필요에 의해서만 쓰인다고 생각했다. 왜냐하면 지금까지는 DTO가 presentation layer에서 persistence layer 까지 다 이동했었으니까.
이런 확장성이 떨어지는 방법에서 벗어나 Entity와 Dto, model을 활용 방법에 따라 적용할 수 있다는 배경지식이 생긴 느낌이다.
출처
https://sowon-dev.github.io/2022/07/14/220714dtovsmodelvsentity/
https://sowon-dev.github.io/2021/09/06/210907Jpa-entityVSDto/
https://blog.aacii.net/307
