[DTO] 왜 Entity와 나눠야하는가에 대한 고민

현재 솔루션을 개발중인 2년차 개발자입니다. 

현재 회사에서는 Object(Entity Class)를 objects 패키지에 전부 넣어두고 Entitiy로 통신을 주고 받고 있습니다. 

고객사 사이트마다 테이블 커스텀이나, 비즈니스 요구사항이 수정될 경우 문제가 있었지만, 큰 비상사태는 없던걸로 기억합니다. (다행히도..?) 문제는 잘 실행되던게 svn에서 update받아서 실행하면 종종 안되는 경우가 있었는데, 확인해보면 Entitiy에 컬럼정보나 이름이 수정되서였습니다. -> 지식이 부족했던 터라,,, udpate받으면 되지~ 커밋이 안됐나보지 했는데 학습을 할수록 이 구조가 잘못됐다는 걸 깨닫고 있네요.

 

현재는 ExtJS, Spring Legacy, mssql 로 솔루션 2.0에 대한 유지보수 및 엔지니어링 업무를 수행하고 있는데, 

최근 국정원 보안기능확인서 취득이 필요해짐에 따라 솔루션 3.0버전에 대한 니즈가 발생했습니다. 이에 보안 코드가 적용된 개발이 필요해서 일명 "새출발"이 필요했는데, 저랑 팀 내에 두분과 함께 재개발을 진행하게 되었습니다.

모든 부분을 재개발할 수 없기때문에 보안관련 부분은 외주에 맡겨 모듈로 받아오고, 저희 VDI 작업을 진행해주던 봇들은 c#으로 대체 개발하게 되었다고 합니다. 

오로지 웹개발에만 정진할 수 있게 되었다!!

 

현재 Vue.js Springboot 2.5.x로 진행하고, 기존에도 Hibernate를 사용했지만, 제 생각엔 하이버네이트, Spring data JPA의 특장점을 다 버린듯한 느낌을 받았습니다. 

이에 Spring Data JPA 학습과 함께 적용을 적극적으로! 하고자 합니다.

 

첫번째 문제인 Entity -> Entity / DTO로 나눠야하는 이유에 대해 알아보자.

 

대부분의 Entity클래스들은 대부분 DB 테이블 스키마와 1:1로 매칭된 형태의 구조를 가지고 있다.

특히 JPA를 사용하는 경우 Entitiy 클래스 = DB 테이블이라고 봐도 될 정도로 거의 동일한 구조를 가진다.

 

DTO를 사용해야하는 이유

- DB 설계와 동일한 객체를 화면에 공개

- 응답 객체가 항상 엔티티와 동일할까.

- 순한참조 문제

- 어떤 값을 요청하고 어떤 값을 응답하는지에 대한 설계서 역할.

 

DTO를 도입함에 있어서 고민되는 부분

- 어디서부터 어디까지 DTO를 사용할 것인가.

- Entitiy -> DTO, DTO -> Entity 변환은 어떻게 할 것인가

- 어떻게 만들것인가. (모든 요청 / 응답마다 클래스 생성?)

 

 

 

 

출처 : https://velog.io/@aidenshin/DTO%EC%97%90-%EA%B4%80%ED%95%9C-%EA%B3%A0%EC%B0%B0

DTO에 관한 생각