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..

개요JPA를 이용해서 쿼리의 결과를 가지고 오는 도중 궁금증이 생겼다. 쿼리의 결과로, 엔티티 객체 자체를 가지고 와서 서비스 로직에서 DTO로 맵핑하는 방법만 머리에 있었다. 그리고 복잡한 데이터가 아니고 단순히 엔티티객체에서 필요한 일부분을 가볍게 가지고 오고 싶다는 생각에서 발단을 하였다. 기존 방식은 엔티티 객체를 map을 돌려 DTO로 변환을 하는 과정에서 자원소모가 클 거 같았고, 찾아보니 DTO 형태로 바로 맵핑을 받는 방법도 있었는데, 이건 JPQL 쿼리에 DTO의 경로명까지 적어주는 방식으로 하는 거 같았다, 이 부분에서 만약에 내가 쓰려는 DTO의 이름이 바뀌거나, 위치가 바뀐다면 곤란하겠는데?라는 생각도 해봤다. 조금 더 맛있는 방법이 없을까?라고 생각을 하던 도중 Projection..

개요 상품에는 카테고리가 있어야 한다, 중고 XX, 당근 XX을 보면 상품을 등록할 때 카테고리를 등록하잖아요? 고민중독이다.. 생각해 보니 카테고리에는 대, 중, 소 분류가 있다. 기존 테이블대로 가지고 간다면. 카테고리 테이블 안에 데이터는? 어떻게 넣어줄 거지?라는 생각이 강하게 들었다. " 문자열이니까 "전자기기/노트북/맥북", "식품/육류/소고기" 이런 식으로 다 넣는 건가? " 물론 단일 카테고리로 간다면 괜찮지만, 우리는 대, 중, 소로 가기로 했기에 뭔가 이상하다는 생각을 했다. 모든 경우의 수를 안에다가 다 넣을 수 없지 않은가.. 고민을 했던 부분"프런트엔드에서 상품을 저장할 때 카테고리를 텍스트로 넘겨줌 그리고 디비에 저장"근데 이건 말이 안 되는 거 같았다, 프런트 엔드에서 카테고리..

개요.API를 만드는 도중, 일어난 고민이다. 상품을 조회하는 로직은 크게 두 가지로 나눌 수 있다.1. 크게 상품에 대한 간략한 정보들만 보여줌(대표이미지, 제목, 가격, 지역 등등)2. 상품 상세조회시 간략한 정보에... 상세정보를 곁들인... 상세조회.(상품에 대한 여러 이미지, 상세정보, 후기, 판매자 정보 등)  그래서 결론이 무엇이냐, 상품에 대한 간략한 정보만 가지고 올 때, 이미지를 불러오는 것 때문에 이미지 테이블에 JOIN이 일어나게 된다. 여기서 든 고민은 "굳이 대표이미지 1장만 필요한데 JOIN을 해야하나 ?, 상품이 한 페이지에 10 개식 뜬다고 했을 때 대표이미지를 위해 10번의 JOIN이 일어날 필요가 있나.." 이 문제를 해결하기 위해 했던 고민들. " one to many..