JustDoEat

개요ProductService에  너무 많은 기능, 메서드들이 들어오게 되었고,  이로 인해 ProductService 혼자서 감당하기에는 책임들이 너무 무거워진다고 생각함. 추가로 다른 서비스에서 ProductService를 의존받아 사용하는 경우에도 상대적으로 가벼운 기능만 필요한데  너무 투머치로 모든 기능들이 보이는 거 같아서 분리를 하고 싶었고, 하나의 클래스가 너무 많은 책임을 가지고 있는 게 싫어서 퍼사드 패턴을 적용해 보기로 했다.퍼사드를 왜 적용을 하려고 했는가?   퍼사드의 정의처럼, 시스템의 복잡성을 감추고, 필요한 기능만 접근할 수 있도록 분리를 해보려고 한다. 퍼사드 패턴과 책임분리가 적절하게 이루어지지 않던 클래스는 아래와 같다. ProductService@Service@Requ..

개요 이미지 파일과 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..

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

개요객체를 생성할 때, 무분별한 Setter를 사용했었다, 이 방법은 영 좋지 않다는 걸 알았다. 왜냐면 객체가 생성이 되어진 시점에서 setName(), setTitle() 이런 식으로 객체의 상태를 바꾸게 된다면 "객체의 불변성"이라는 원칙을 깨버릴 수도 있기 때문이다, 한번 만들어진 객체는 가급적 수정이 일어나면 안되기 때문이다. 아 이걸 깨달은 건 다른 레포지토리들을 보면 @Builder 어노테이션을 사용한 걸 눈여겨보다 이 친구는 뭐 하는 친구인지 너무 궁금했다. @Builder 어노테이션은 결국 Builder패턴을 구현한 거기 때문에, 본래의 것을 쓸 줄 알아야 의미가 있다고 생각한다.(이러고 그냥 쓰는 것도 많지요~.. 하하..)  객체생성과 동시에 생성자를 이용해 값을 초기화, 기본생성자로..