없는 id로 delete 요청시 예외처리를 담당하는 클래스 #124
yxxnghwan
started this conversation in
[BE] 컨벤션 이슈
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
현재 Member 도메인에서는 Service에서 findById로 해당 엔티티를 조회하고 없으면 예외를 터트리고 있으면 삭제하는 로직을 가지고 있고,
Team도메인에서는 Repository에서 delete 명령문의 affectedRow를 반환받아 1이 아니면 예외를 터트리는 로직을 가지고 있습니다.
처리 방식이 나뉘어서 다른 팀원들 의견을 같이 들어보고자 합니다.
전자의 처리방식의 장점은 비즈니스 예외를 터트리는 로직을 Service레이어에 응집시켜 어떤 비즈니스 로직에서 어떤 예외가 터질 지 Service코드만 보고 한눈에 파악할 수 있다는 장점이 있구요,
후자의 처리 방식은 쿼리를 2번 날려야 하는 전자의 방식에 비해 한번의 쿼리로 예외처리를 할 수 있지만, 예외를 레포지토리에서 처리해야한다는 단점이 있습니다.
개인적인 의견은 해당 예외케이스를 비즈니스 예외로 볼 건지, DB예외로 볼 건지에 따라 다를 것 같은데요.
비즈니스 규칙상 없는 id로 삭제 요청시 예외가 발생한다는 로직의 예외인지,
DB에 삭제요청을 했으나 DB가 기대한 대로 동작하지 않았기 때문에 DB예외로 볼 건지가 중요할 것 같아요.
만약 비즈니스 예외라면 Service에서 핸들링 하는 게 맞고, DB예외로 본다면 Repository에서 핸들링 하는게 좋아보입니다!
추가적인 의견)
각각의 책임과 역할에 맞게 DB에서 affectedRow가 1이 아닐 경우에 NotFoundException이 아니라 스프링 DB에 정의된 DB예외클래스를 던지고,
서비스에서 그 DB예외를 캐치해서 비즈니스 예외로 바꾸는 것은 어떨까요?
저희가 현재 작성한 두 케이스의 장점을 모두 갖출 수 있지만(비즈니스 예외 응집, 쿼리 1번), try-catch문이 추가되어야 하는 만큼 코드 생산량이 늘어나는 단점이 있겠네요.
자유롭게 의견 토론 부탁드려요!😁
Beta Was this translation helpful? Give feedback.
All reactions