JustDoEat

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

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

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

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