xxPatric
10
2019-08-09 19:04:24
4
163

JPA DTO Mapping 관련 질문이 있습니다.


안녕하세요 !

Spring Boot + Gradle + JPA를 공부하고있는 학생입니다.

공부하면서 프로젝트를 진행하고 있는데 구현하고 싶은 기능이 있습니다.

몇가지 키워드로 찾아보아도 개념이 안잡혀있어서 사용하기가 어려워 문의드립니다.

기초적인 질문이여도 양해 부탁드립니다.


전체적인 상황은 다음과 같습니다.

1. 사용자(USER)는 학과(Department)에 속해있습니다.
2. 사용자는 주문(ORDER)를 할 수 있습니다.
3. 주문(ORDER)는 주문 항목(ITEM)을 가지고 있습니다.


궁금한 부분은

1. 특정 학과(Department)를 기준으로 몇명의 사용자(USER)가 존재하는지

2. 해당 학과(Department)가 몇개를 주문(ORDER) 했는지

3. 해당 학과(Department)가 몇개의 아이템(ITEM)을 주문했는지


3가지 사항에 대해 출력 값을 얻고 테이블의 형태로 출력하려고 합니다.


DEPARTMENTUSER NUMBERODER NUMBERITEM NUMBER
AAA10618
BBB51124


이렇게 출력을 하려면 JPA Entity와 결과값을 출력할 DTO를 만들어야하나요?

아니면 다르게 출력할 수 있는 방법이 있을까요


너무 두서 없이 질문했지만 간단한 방향성이라도 알려주시면 감사드립니다.





0
0
  • 답변 4

  • 제타건담
    6k
    2019-08-09 19:13:15

    DTO는 클라이언트..와 밀착된 설계를 하면 됩니다..

    여기서 클라이언트..라고 하는건 화면일수도 있고 REST API일수도 있어서 이렇게 표현했지만..

    클라이언트에서 이용하는게 DB 와 반드시 같은 구조일수는 없습니다..

    JPA 엔티티는 모델 설계 개념으로 설계하고 이를 바탕으로 DB 테이블을 만드는 것이어도..

    그 모델..이란게 실제 클라이언트와 동일한 형태를 갖고 있지는 않습니다..

    예를 들어 엔티티를 설계할때 주소를 하나로 묶어서 클래스를 만들고 그 내부에 우편번호, 주소2 이렇게 멤버변수를 두어서 설계를 하지만..

    클라이언트에서는 주소..라고 묶는게 아니라 그냥 우편번호, 주소1, 주소2 이렇게 바로 필드로 설계해버리는거죠..

    그래서 DTO와 엔티티가 자신이 서로 상대방으로 변환해주는 메소드를 제공해주면 그 메소드를 통해서 변환해서 return 해주면 되니까요..

    그런 개념으로 접근해보시면 될 듯 하네요..

    1
  • xxPatric
    10
    2019-08-09 20:14:53

    답변 감사합니다. 제타건담님


    제가 생각한 방법은 테이블로 출력될 값에 맞춰 DTO를 생성하려고 했는데 해당 방법은 너무 클라이언트 의존적이기때문에 피해야할 것 같습니다.


    제타건담님의 답글을 보고 제가 드는 생각은 DTO는 좀더 큰 범주로 생각해야할 것 같은데

    DTO를 여러개의 엔티티를 조합하여 만들고 각 테이블에 출력될 값들을 메소드의 형태로 로직을 짜서 제공해야하나 라는 생각이 듭니다...


    이런 방향이 맞을까요??

    0
  • 제타건담
    6k
    2019-08-09 23:50:17

    정해진 규칙은 없어요..

    지금 하시는게 사용자 정보, 부서, 주문, 상품..이 4가지인거 같은데..이걸 기준으로 썰을 풀어볼께요..

    사용자 정보를 등록, 수정, 삭제 하는 화면에서는 사용자 정보 DTO와 사용자 정보 엔티티가 동일할껍니다..

    근데 만약 특정 사용자가 구매한 주문 리스트를 사용자 상세 정보를 보여줄때 같이 보여주고 싶다면..

    엔티티를 설계할때는 사용자 엔티티에 주문 엔티티 목록을 저장하는 멤버변수를 같이 두게끔 설계하겠죠..

    그러나 DTO로 이를 표현할때는 사용자 DTO 하나와 LIST<주문 DTO> 요런 식으로 2개로 나누어서 보내는게 낫습니다..DTO를 설계할때 사용자 DTO 안에 LIST<주문 DTO> 멤버변수를 두어서 엔티티와 같은 구조를 갖게끔 할 수도 있지만 그렇게 할 경우 사용자 상세정보에 주문 리스트를 보여주는 경우를 제외하고는 사용자 등록, 수정, 삭제 할때는 LIST<주문 DTO>가 아무 소용이 없기 때문이죠..순수하게 사용자 정보와 관련된 작업만 할때는 그러한 설계의 DTO는 효용성이 떨어지기 때문이죠..왜냐면 그 부분이 안쓰이니까요..

    그래서 DTO를 여러 엔티티의 조합으로 만드는게 좋은 상황도 있고 그렇지 않은 상황도 있기 때문에 그렇게 DTO를 만들었을때 내가 현재 구현하고자 하는 기능에 있어서 이러한 설계의 DTO가 과연 효용성이 좋으냐..에 대한 고민을 해야 하는 부분이 있는거죠..하나의 DTO안에 여러 엔티티 조합을 통해서 만드는것이 좋다 나쁘다..이런 개념이 아니라..이렇게 만들었을 경우 내가 현재 구현하고 있는 기능에서 이를 사용할때 불필요한 멤버변수가 추가된 형태로 운영되는 상황이 빈번한지 확인해보고 그게 빈번할 경우엔 차라리 분리하는게 나은거죠..

    1
  • xxPatric
    10
    2019-08-10 11:51:56

    좋은 말씀 감사합니다. 많은 고민을 하면서 설계를 해야겠네요.

    시간 내서 답변해주셔서 감사합니다.


    0
  • 로그인을 하시면 답변을 등록할 수 있습니다.