JustDoEat

개요 이미지 파일과 Json형식의 데이터를 같이 보내야 하는 상황에서. MultipartFile 타입의 인자를 클라이언트로 받음과 동시에 컨트롤러에서 DTO에 한 번에 맵핑시키고 싶었다. 하지만 일반적인 DTO 맵핑과 다르게 맵핑이 되지 않아 골머리를 썩고 있었다.   문제 해결을 위해 각 특성을 살펴보고 해결해 보겠다.RequestBody, RequestParam, RequestPart RequestBody Content-Type이 application/json 인 데이터를 받을 때 우리가 통상적으로 많이 쓰는 어노테이션이다. HTTP 요청의 본문의 데이터를 DTO의 필드 값과 맵핑을 시켜줄 때 사용한다.  @Getterpublic class ReviewCreateReqDto{ private final..

개요제이슨 형식의 본문과, 이미지 파일을 같이 받아야 하는 상황이 생겼다. 여기서 문제는 application/json과 multipart/form-data 형식을 같이 받아야 하는데 application/json 같은 경우는@Validated 어노테이션을 붙임으로써 클라이언트가 요청을 잘못 보내면 DTO선에서 컷 해버린다. (DTO는 데이터를 옮기는 책임만 치는데 사실 컨트롤러단에서 요청에 대한 유효성을 DTO에서 검증을 하는 게 말이 되는 건가 싶다..그냥 값을 받고, 엔티티 객체 생성시점에 입력을 검증하는 방식으로 바꿔야 하나 고민 중이다.)여하튼 RequestDto에 한에서만 검증의 책임도 같이 주었다.. PNG, JPG, JPEG의 확장자만 와야 하는데. 만약 이상한 파일을 보냈다면? 일반적인 ..

개요.상품 검색 기능을 리팩터링 하는 중, 의문이 생김.. 일단! 제목으로 검색만 만들고(지금까지는 이렇게 하기로 함.) 나중에 태그별, 위치별로 상품을 검색하는 기능을 만들려고 하는데(추후 고도화 때나 할거 같음) 처음에는 단순하게 if문을 써서, "제목별", "태그별", "위치별" 단어를 구분해서 거기에 맞는 서비스를 호출하려고 했는데.. 검색 관련 로직이 추가되거나 영역이 확장된다면 그만큼 if문도 늘어나고 아무리 봐도 더 좋은 방법이 있지 않을까 해서 찾아보다 발견했다. 대충 어떤 느낌이었냐면 일단, 우테코 프리코스 찍먹을 하면서 if-else문은 가독성을 떨어뜨리므로 가급적 삼가야 한다고 들었다. 그럼 조건에 따라 서비스를 주입하고 싶다...라는 생각? 에서 나온 기가 막힌 방법!! 그것은 전략..

개요🗣️  팩토리 메서드는 객체 생성의 책임이 있다고 알고있음.🗣️ 🗣️ 서비스 클래스에서는 응집도를 위해 유사한 성격을 가진 기능들을 모아야 한다고 알고있음. ❓ 이 두가지 생각에 대한 충돌 ❓진행여기서 드는 의문Review를 생성하기 위해서는 User Entity 객체와, Product Entity 객체를 받아야 한다. 상황클라이언트가 리뷰를 등록하기 위해서는, 리뷰의 내용, 평점을 입력할 것이고. 작성완료를 누르면 프런트엔드에서는 해당 리뷰에 대응되는 productId를 넘겨줄 것이다. Case 1.@Service@RequiredArgsConstructorpublic class ReviewServiceImpl implements ReviewService{ private final Revi..

개요https://kingmusung.tistory.com/71 Data JPA, DTO, Projection 방식중 적합 한 방식을 찾아보았다.개요.JPA를 이용해서 쿼리의 결과를 가지고 오는 도중 궁금증이 생겼다. 쿼리의 결과로, 엔티티 객체 자체를 가지고 와서 서비스 로직에서 DTO로 맵핑하는 방법만 머리에 있었다. 그리고 복잡한kingmusung.tistory.com Projection과 DTO 방식 중 적합한 방식을 찾던 중, 계속 궁금증이 생겼다.  간단한 쿼리에서 Projection이 가독성도 좋고 작성하기도 편한데, 과연 속도도 빠를까?   여기서 id, mainImage, title, price만 가지고 오려고 한다.  DTO@Getter@Builderpublic class Product..