나의 프레임워크 설계 ref 스프링

오늘은 DTO 설계에 관한 것이다

일반적으로 DTO를 사용할때 DB의 테이블에 맞춰서 만드는게 일반적이었다.

하지만 나는 조금 다른 방법을 생각했다. 클라이언트 기능에 맞춰서 DTO를 설계 할것이다.

먼저 다음과 같이 DB 테이블이 있다.

<Board>

boardId

title

contents

createDate

createId

count

nickname

password

company

joinDate

이러한 테이블이 있을때 DTO는

이렇게 만들고 클라이언트 딴에서 따로 따로 불러온다.

하지만 더좋은 방법을 생각했다. DTO를 클라이언트 의 기능에 따라 관계를 설정 해주는 것이다.

1:1 관계는 다음과 같이 오브젝트로

1:n 관계는 List로 설정해준다.

이렇게 DTO를 만들면 비즈니스 모델은 조금 더 복잡해질 수 있다.

하지만 설계가 조금 더 명확해지고 클라이언트에서 매핑할 때 매우 편리하다.

그리고 이러한 방향으로 DTO설계를 했을 때 같이 개발하는 친구들이 더 쉽게 이해할 수 있었다.

(DTO를 먼저 설계해서 뭔가 개발의 방향이 보인다고 할까?)

하지만 기획 및 설계가 좀 명확하지 않으면 불필요한 DTO 객체들이 엄청 늘어난다.

그리고 데이터양이 많은 모니터링 시스템에는 적합하지 않은 것 같다.

특히!! 1:n관계에서 많은 양의 데이터를 처리해야하는 상황에서는 사용하지 않는 것이 좋다.

while(0){ sleep(0);}