오봉이와 함께하는 개발 블로그

회원 수정 API @Data static class UpdateMemberRequest { private String name; } @Data @AllArgsConstructor static class UpdateMemberResponse { private Long id; private String name; } @PostMapping("/api/v2/members/{id}") public UpdateMemberResponse updateMemberV2(@PathVariable("id") Long id, @RequestBody @Valid UpdateMemberRequest request) { memberService.update(id, request.getName()); Member findMember..

회원 등록 API 이전 코드 : https://github.com/rhqudco/SpringLearn/tree/master/jpashop V1 엔티티를 Request Body에 직접 매핑 @RestController @RequiredArgsConstructor public class MemberApiController { private final MemberService memberService; @PostMapping("/api/v1/members") public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member) { Long id = memberService.join(member); return new CreateMemberRes..

코드 해당 내용을 설명하기 전 강의에 있는 코드는 아래 Github링크를 참조하자. https://github.com/rhqudco/SpringLearn/tree/master/jpashop 변경 감지와 병합 영속 상태의 엔티티는 변경이 감지되면 따로 persist 하지 않아도 JPA가 커밋 시점에 DB에 알아서 반영을 해준다. 이것을 변경감지(Dirty Checking)라고 한다. 문제는 준영속 엔티티다. 준영속 엔티티? 영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다. 예를 들어 이미 DB에 저장했던 값을 다시 조회해서 JPA가 식별할 수 있는 식별자가 있고, 그것을 다시 객체 상태로 만든 것을 준영속 상태의 객체라고 한다. @PostMapping("/items/{itemId}/edit") pub..

엔티티 설계시 주의점 엔티티에는 가급적 Setter를 사용하지 말자 Setter가 모두 열려있다. 변경 포인트가 너무 많아서, 유지보수가 어렵다. 나중에 리펙토링으로 Setter 제거하자. 모든 연관관계는 지연로딩으로 설정 @ManyToOne(fetch = FetchType.LAZY) 즉시로딩(EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 즉시로딩을 하면 연관된 테이블을 모두 조회하는 것이다. 예를 들어 Member를 조회하면 Order를 조회하고 Order와 연관된 모든 테이블을 모두 다 조회한다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다. 실무에서 모든 연관관계는 지연로딩(LAZY)으로 설정해야 한다. 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch j..

엔티티 클래스 개발 엔티티 클래스에 Getter, Setter를 모두 열고, 최대한 단순하게 설계 실무에서는 가급적 Getter는 열어두고, Setter는 꼭 필요한 경우에만 사용하는 것을 추천 참고 이론적으로 Getter, Setter 모두 제공하지 않고, 꼭 필요한 별도의 메서드를 제공하는게 가장 이상적 이다. 하지만 실무에서 엔티티의 데이터는 조회할 일이 너무 많으므로, Getter의 경우 모두 열어두는 것이 편리하다. Getter는 아무리 호출해도 호출 하는 것 만으로 어떤 일이 발생하지는 않지만, Setter는 문제가 다르다. Setter를 호출하면 데이터가 변한다. Setter를 막 열어두면 가까운 미래에 엔티티가 도대체 왜 변경되는지 추적하기 점점 힘들어진다. 그래서 엔티티를 변경할 때는 S..