발단
진행중인 프로젝트도 시작할때는 파일이 몇개 없었는데, 개발을 하다 보니까 파일들이 하나씩 쌓이기 시작한다. 그 중에 가장 눈에 띄게 많아진 파일들이 있다면..
dto 파일들과 모델 파일들이다. dto와 모델에 대해서 깊게 공부한 적은 없지만, 개인적인 판단으로 dto는 컨트롤러 레이어와 서비스 레이어, 데이터베이스 간의 데이터 교환을 위한 모델로 사용하고, 모델 폴더의 파일들은 프론트엔드에서 받아오는 request들의 body에 대한 값 검증, 데이터 모델 생성을 위해서 사용하고 있었고, 백엔드에서 프론트엔드로 데이터를 전송하기 위한 데이터 모델로 사용하고 있었다.
그런데 필요할때마다 하나씩 생성하거나, 더 필요한 필드가 있을때 하나씩 생성하다 보니까 모델들 간의 네이밍이나 모델과 dto들의 사용이 모호해지고, 내가 정확하게 모델과 dto를 구분해서 사용하고 있는지에 대해서 생각해보게 되었다.
의문이 든 김에 dao, dto와 model과 dto를 분리시켜야 하는지, 혹은 같은 폴더에 몰아넣오도 될지 생각해보고자 한다.
DAO
DAO란, data access objeect 라고 실제로 DB에 접근하는 객체이다. Persistence Layer, 즉 DB에 데이터를 crud하는 게층에서 사용되며 service와 db를 연결하는 고리가 된다.
DTO
DTO란, data transfer object 라고 해서 계층간 데이터 교환을 위한 객체이다. db에서 데이터를 얻어 service나 controller등으로 보낼 때 사용하는 객체를 말한다. 로직을 가지지 않으며, DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 setter가 필요하지 않다. 대신 생성자에서 값을 할당하고 이 값을 꺼내쓰는 경우가 대부분이다.
VO와 DTO?
VO는 DTO와 동일한 개념이지만 readoonly 속성을 갖는다. 특정한 비즈니스 값을 담는 객체이지만, DTO는 layer간의 통신 용도로 오고 가는 객체를 말하게 된다.
내 프로젝트에서 적용 방법
원래 목적이였던 DTO와 Model의 명칭에서 분리해서 이해해야 하는지, 아니면 어떻게 받아들여야하는지에 대해서는 명확하게 결정하지는 못했다. 하지만 대부분의 글들에서 Model은 더 관념적인 호칭이고 그것을 구현한 것이 DTO, VO같은 형태라고 한다. 결국 내가 만들어놓은 것들이 DTO와 DAO들인데, DAO를 DTO라고 이름붙여서 쓰고 있고 프론트와 백엔드를 연결할떄 사용하는 DTO를 모델이라고 이름붙여서 사용하고 있는 모양이였다. 그런데 VO는…. 내가 사용하고 있는 프로젝트에서 VO의 형태를 하는게… 쿼리문 저장한 오브젝트나 html 셀렉터 데이터 저장한 오브젝트가 VO의 모습이라고 생각된다. 이 값들은 Readonly 로 걸어놨으니 안심!
일단 우선과제로 dto와 model들 용도에 맞는 네이밍으로 변경하고 네이밍도 통일시켜야겠다!