JPA활용 2 - 회원수정

Rest API

• HTTP 프로토콜을 통해 API를 설계하기 위한 아키텍쳐스타일

• 뛰어난 유연성

• 개발자들 사이에 널리 알려진 약속

GET : 조회, READ

Post : 등록 create

Put : 변경 , Update

delete : 삭제

로 거의 사용함.

수정은 PutMapping을 통해 진행

UpdateMember 관련 DTO를 만들 때 Controller내부에서만 사용될 경우에는 Inner 클래스로 만들어도 된다.

• 어쩌피 내부에서만 사용되기 때문에

만약 다른 곳에서도 사용할 거라면 따로 클래스를 생성해서 만드는 게 좋다.

DTO는 대충 데이터를 전송만하는게 중점이기 때문에 Lombok 어노테이션을 여러개 쓸데가 있음

Entity에 경우에는 어노테이션을 제한적으로 몇개만 쓴다. Getter와 같은 엔티티가 변경되지 않는 선에서

이전과 마찬가지로 Transcational안에서 영속성 상태에서 변경감지를 이용해서 변경하는게 가장 좋기 때문에 MemberService에 update함수를 만들어서 보내준다.

Controller단

    @PutMapping("api/v2/members/{id}")
    public UpdateMemberResponse updateMemberV2(@PathVariable("id") Long id
            , @RequestBody @Valid UpdateMemberRequest request) {

        memberService.update(id, request.getName());

//아직         return new UpdateMemberResponse(id, request.getName());
    }

---

Service 단

@Transactional
public void update(Long id, String name) {
    Member member = memberRepository.findOne(id);
    member.setName(name);
}

update에서 사실 Member를 반환시켜도 상관 없긴하다. 하지만 이렇게 되면 Command와 Query가 분리되지않고 같이 사용하는 꼴이 된다.

• update의 경우 객체의 상태를 변경하는 메서드로 Command 쪽 부분이고 만약 Member를 반환하게 되면 id를 통해서 Member를 다시 조회하는 구조가 되기 때문에. -> 분리가 일어나지 않음.
• 내부에서 변경(사이드 이펙트)가 일어나는 메서드인지, 아니면 내부에서 변경이 전혀 일어나지 않는 메서드인지 명확히 분리하는 것을 개발 전제로 가져가는 게좋기 때문에
• 이렇게 분리를 하게 될 경우 데이터 변경 관련 이슈가 발생하면 전체를 뒤지는게 아니라 데이터 변경이 일어나는 메서드만 찾아보면 되기 때문이다.
  • 따로 질문들을 찾아보니 권장하는 방법은 insert일 경우 id 정도만 반환(조회는 해야하기 때문에) ,update의 경우는 반환하지 않고, 조회는 내부의 변경이 없는 메서드로 설계하자.
  • CQRS - 인프런 | 질문 & 답변 (inflearn.com)

강사님은 Command 와 query를 분리하자는 주의라서 Member를 반환시 영속성이 끊긴 객체가 반환되기 때문에 별로 선호하지 않는다고 함. -> 이렇게 말하는 이유가 실무에서는 OSIV를 끄고 개발을 하기 때문인거같음.

• 만약 반환해준다면 id 정도는 반환 해주는 편 -> 찾는건 필요할 수 있기 때문에