티스토리 뷰

회원 정보 조회하는 경우, 탈퇴처리된 상태의 회원은 조회가 안되도록 예외처리를 해야하는 상황이 있었다.

 

당시 controller-service의 역할에 대한 개념이 불명확해서 어디서 예외처리를 해줘야하는지 고민을 한참 했었다.(ㅎㅎ..하하)

 

그러다가 나와 비슷한 고민을 하는 분의 질문에서

프로그래밍 로직을 이렇게 한다는 답변을 보게 되었다.

" view -> validation logic -> business logic -> dao "

 

보통의 view는 controller에서 처리하고, 여기서 예외처리는 validation logic에 해당하므로 service에 넣어주는게 맞다고 생각했다.

 

그리고 아주 단적으로 controller가 없더라도 API 로직은 정상적으로 돌아가야한다는 김영한님의 답을 어디선가 보고

controller에서는 비즈니스 로직에 대한 판단을 내려서는 안되고 클라이언트에서 받아온 데이터를 전달, 비즈니스 처리 결과를 받기만 해야한다는 깨달음을 얻었다…

 

 

그래서 이렇게 돌아가도록 만들었다.

controller : service 호출 -> 처리 결과 반환

@GetMapping("/me")
fun me(): ResponseEntity<Response> {
    val result = Response.of("결과 코드", memberService.getInfo())
    return ResponseEntity(result, HttpStatus.valueOf(result.status))
}

ResultResponse.of

정적 팩토리 메소드 : 객체 생성을 생성자가 아닌 정적 static 메서드로 하는 것

명명규칙 of : 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메소드

Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);

 

service : 회원 정보 조회해서 탈퇴 상태에 따라 예외처리

@Transactional(readOnly = true)
fun getInfo(): MemberDto {
    val member = memberRepository.findByUserId(userId) ?: throw CustomException(ErrorCode.MEMBER_DOES_NOT_EXISTS)
    if (member.deleted) throw CustomException(ErrorCode.MEMBER_DELETED)
    return members.toDto()
}
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함