Entity & DTO Vo 적용

[NDjust]

제가 지난 미션에서 활용한 VO을 현재 @Embeddable로 만들어서 Entitiy Column으로 활용하고 있는데,

{ "orderMenuId": "id", 
    "amount": {
              "value": 1.0 
       },
}

Response 시에 위와 같이 JSON Serializing 이슈가 발생해서 Dto에는 VO을 사용하지 않고, 원시값을 통해서 전달하고자 하는데, 그렇게 되니 getValue(), getValue()로 체이닝이 되는 느낌이라 코드가 좀 보기 않좋더라고요.

그리고 Entity는 일반 객체와 달리 DB에 저장하고, 추출하는거지 과연 비즈니스 로직이 반영된, VO Column을 넣어서 설계하는게 맞는지에 대한 의문도 드네요!

정답은 없겠지만, 다른 분들의 조언이나 의견을 듣고 싶습니다!

추가 질문

• Dto To Entitiy 혹은 Entity To Dto로 변환 시 다들 Mapper을 따로 구현해서 적용하시나요?!
  • 구글링 해보니 Visitor Pattern 을 활용하는 분도 계시고, Builder 패턴으로 하시는 분도 계시고 좀 다양하더라고요.
  • Mapper를 구현하자니, Mapper 클래스 또한, Dto와 Entitiy의 필드가 수정되면, Mapper 도 전체적으로 수정이 되야해서 결합도가 높아진다는 생각이 들어서 질문드립니다.

[pci2676]

Response 시에 위와 같이 JSON Serializing 이슈가 발생해서..

위와 같이 라고 하신 부분이 @Embeddable 한 VO가 Serialize 되지 않았다는 말씀이신가요?? 해당 VO의 코드 + 깃헙에 코드 Push 하시고 해당 코드 부분을 링크해주시면 더 정확히 알아볼 수 있을것 같아요!

[pci2676]

Dto To Entitiy 혹은 Entity To Dto로 변환 시 다들 Mapper을 따로 구현해서 적용하시나요?! 구글링 해보니 Visitor Pattern 을 활용하는 분도 계시고, Builder 패턴으로 하시는 분도 계시고 좀 다양하더라고요. Mapper를 구현하자니, Mapper 클래스 또한, Dto와 Entitiy의 필드가 수정되면, Mapper 도 전체적으로 수정이 되야해서 결합도가 높아진다는 생각이 들어서 질문드립니다.

이 경우는 사람마다 다를것 같긴한데 저는 Builder를 Entity에 생성해 두고 dto의 필드를 하나하나 get 해서 넣어줍니다! 혹은 Entity를 생성하는 정적 Factory 클래스를 하나 만들어서 사용하기도 합니다!

그런데 Builder가 생가는부분도 정말 이렇게 많은 파라미터가 필요한가? 라고 의심해 볼 수 있는 포인트가 될 것 같아요! 보통 Builder는 매개변수가 4~5개를 넘어갈 때 사용하는데 파라미터의 갯수를 줄일 수 있는지 한번 고민해 보셔도 좋을 것 같습니다!

[NDjust]

Response 시에 위와 같이 JSON Serializing 이슈가 발생해서..

위와 같이 라고 하신 부분이 @Embeddable 한 VO가 Serialize 되지 않았다는 말씀이신가요?? 해당 VO의 코드 + 깃헙에 코드 Push 하시고 해당 코드 부분을 링크해주시면 더 정확히 알아볼 수 있을것 같아요!

아뇨! quantity를 VO로 사용하면 아래와 같이 Serialize하게, quantity vo 객체에 value값으로 꺼내와야해서요!

이렇게 되면, VO에 대해서 Dto에게 전달할때 orderMenu.getQuantity().getValue() 이런식으로 get이 체인으로 묶여서 별로 좋지 못한 코드인 거 같아 질문드립니다!

package com.javabom.cafe.domain.menu;

import com.javabom.cafe.domain.table.CafeTable;
import com.javabom.cafe.domain.vo.Amount;
import com.javabom.cafe.domain.vo.Quantity;

import javax.persistence.*;

@Entity
public class OrderMenu {

    // TODO Refactoring & Web 요구 사항 정리해서 맵핑 정리하기.
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "table_id")
    private CafeTable table;

    @ManyToOne(fetch = FetchType.LAZY)
    private Menu menu;

    @Embedded
    private Quantity quantity;

    private OrderMenu() {
    }

    public OrderMenu(final Menu menu, final CafeTable table, final int quantity) {
        this.menu = menu;
        this.table = table;
        this.quantity = Quantity.valueOf(quantity);
    }
    public OrderMenu(final Menu menu, final Quantity quantity) {
        this.menu = menu;
        this.quantity = quantity;
    }
}

{ "orderMenuId": "id", 
    "quantity": {
              "value": 1.0 
       },
}

[NDjust]

Dto To Entitiy 혹은 Entity To Dto로 변환 시 다들 Mapper을 따로 구현해서 적용하시나요?! 구글링 해보니 Visitor Pattern 을 활용하는 분도 계시고, Builder 패턴으로 하시는 분도 계시고 좀 다양하더라고요. Mapper를 구현하자니, Mapper 클래스 또한, Dto와 Entitiy의 필드가 수정되면, Mapper 도 전체적으로 수정이 되야해서 결합도가 높아진다는 생각이 들어서 질문드립니다.

이 경우는 사람마다 다를것 같긴한데 저는 Builder를 Entity에 생성해 두고 dto의 필드를 하나하나 get 해서 넣어줍니다! 혹은 Entity를 생성하는 정적 Factory 클래스를 하나 만들어서 사용하기도 합니다!

그런데 Builder가 생가는부분도 정말 이렇게 많은 파라미터가 필요한가? 라고 의심해 볼 수 있는 포인트가 될 것 같아요! 보통 Builder는 매개변수가 4~5개를 넘어갈 때 사용하는데 파라미터의 갯수를 줄일 수 있는지 한번 고민해 보셔도 좋을 것 같습니다!

엇 근데 Entity 같은 경우 DB Table 구조에 따라 의존적인 것인데, Entity에 생성에 대한 Builder의 매개변수가 많으면 문제가 될 수 있는 건가요?!