@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class CouponPolicyRequestDTO {
private BigDecimal minOrderPrice;
private BigDecimal salePrice;
private BigDecimal saleRate;
private BigDecimal maxSalePrice;
private String type; }해당 코드는 현재진행중인 프로젝트의 couponPolicy dto코드다.
일반적으로 dto class에는
@Getter, @NoArgsConstructor 정도를 써주고
나머지는 프로젝트를 진행하면서 상황에 맞게 사용해주면 될 것 같다.
그렇다면 왜 해당 어노테이션을 써야할까?
1. dto의 경우 컨트롤러에서 @RequestBody를 통해 역직렬화 하여 가져옴.
2. 그때 바인딩을 ObjectMapper가 수행함.
3. 바인딩시 일반적인 상황에서는 기본 생성자가 꼭 필요하나 @JsonProperty, @JsonAutoDetect 등을 사용한 Property 기반 클래스이거나, 생성자가 위임된 경우라면 필요하지 않음.
4. 다른 옵션들은 각 dto 클래스마다 일반화해서 사용하기가 어렵기 때문에 @NoArgsConstructor를 사용함.
5. 역직렬화시 reflection을 수행하기때문에 dto의 필드역시 ObjectMapper가 reflection을 통해 Setter or Getter가 있어야만 가져올 수있음.
6. 결론 역직렬화시에는 @Getter, @NoArgsConstructor를 쓰고,
직렬화시에는 @Getter을 쓰는 것을 원칙으로 하자!
사실 우리팀은 그냥 record를 쓰기로 함.
그리고 어쩔 수 없이 객체수정이 필요한경우는 record가 아닌 class타입으로 바꿔서 디테일을 수정해주기로 함.
⚙️ 출처: https://codingwell.tistory.com/182
⚙️ 출처: https://aha2246.tistory.com/126
⚙️ 출처: https://velog.io/@conatuseus/RequestBody%EC%97%90-%EC%99%9C-%EA%B8%B0%EB%B3%B8-%EC%83%9D%EC%A0%95%EC%9E%90%EB%8A%94-%ED%95%84%EC%9A%94%ED%95%98%EA%B3%A0-Setter%EB%8A%94-%ED%95%84%EC%9A%94-%EC%97%86%EC%9D%84%EA%B9%8C-2-ejk5siejhh
