[Project] Lv_5 스케줄 프로젝트

목차

1. 요구사항
2. 요구 구현
3. 회고

 

---

 

요구사항

설명

• ✅ 예외 상황에 대한 처리를 위해 HTTP 상태 코드(링크)와 에러 메시지를 포함한 정보를 사용하여 예외를 관리할 수 있습니다.
  1. 필요에 따라 사용자 정의 예외 클래스를 생성하여 예외 처리를 수행할 수 있습니다.
  2. @ExceptionHandler를 활용하여 공통 예외 처리를 구현할 수도 있습니다.
  3. 예외가 발생할 경우 적절한 HTTP 상태 코드와 함께 사용자에게 메시지를 전달하여 상황을 관리합니다.

조건

• ✅ 수정, 삭제 시 요청할 때 보내는 비밀번호가 일치하지 않을 때 예외가 발생합니다.
• ✅ 선택한 일정 정보를 조회할 수 없을 때 예외가 발생합니다.
  1. 잘못된 정보로 조회하려고 할 때
  2. 이미 삭제된 정보를 조회하려고 할 때

 

---

 

요구 구현

❗예외처리가 포함되지 않는 클래스, 메서드 등 로직은 넣지 않았습니다.

 

ScheduleServiceImpl

 

1. 기본 구조 : ScheduleService 인터페이스를 상속받은 상태

@Service
public class ScheduleServiceImpl implements ScheduleService{

    private final ScheduleRepository scheduleRepository;

    public ScheduleServiceImpl(ScheduleRepository scheduleRepository) {
        this.scheduleRepository = scheduleRepository;
    }

    // 오버라이딩된 메서드가 구현될 곳
}

• 이 아래 메서드들은 모두 위의 주석에 위치해 있습니다.

 

 

2. saveSchedule()

@Override
public ScheduleResponseDto saveSchedule(ScheduleRequestDto requestDto) {
    // 등록된 user인지 userId로 검증
    Integer userCount = scheduleRepository.findUserByUserId(requestDto.getUserId());

    // userCount가 0이면 비등록 유저, 1이면 등록 유저
    if (userCount == null || userCount == 0) {
        throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "This user doesn't exist.");
    }

    Schedule schedule = new Schedule(requestDto.getUserId(), requestDto.getToDoContent());
    return scheduleRepository.saveSchedule(schedule);
}

 

 

3. findScheduleById()

@Override
public ScheduleResponseDto findScheduleById(long id) {
    Schedule schedule = scheduleRepository.findScheduleById(id);

    if (schedule == null) {
        throw new ResponseStatusException(HttpStatus.NOT_FOUND, "This schedule Does not exists (schedule id : " + id + ")");
    }

    return new ScheduleResponseDto(schedule);
}

 

 

4. updateToDoContent()

@Override
public void updateToDoContent(long id, Long userId, String toDoContent) {
    // 필수값 검증
    if (toDoContent == null) {
        throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "The userName and toDoContent are required values.");
    }

    // 유효한 사용자인지 검증
    Schedule schedule = scheduleRepository.findScheduleByUserId(userId);

    if (schedule == null) {
        throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "This user doesn't exist.");
    }

    if (userId != schedule.getUserId()) {
        throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "The userId is not the same as the userId for this schedule");
    }

    // 식별자의 schedule 없다면?
    int scheduleCount = scheduleRepository.updateToDoContent(id, toDoContent);

    if (scheduleCount == 0) {
        throw new ResponseStatusException(HttpStatus.NOT_FOUND, "This schedule Does not exists (schedule id : " + id + ")");
    }
}

 

 

5. deleteSchedule

@Override
public void deleteSchedule(long id, long userId) {
    // 사용자 ID 검증
    if (userId != scheduleRepository.findScheduleByUserId(id).getUserId()) {
        throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "The password is not the same as the password for this schedule");
    }

    int deletedRow = scheduleRepository.deleteSchedule(id);

    // NPE 방지
    if(deletedRow == 0) {
        throw new ResponseStatusException(HttpStatus.NOT_FOUND, "Does not exist id = " + id);
    }
}

 

 

6. GlobalExceptionHandler

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResponseStatusException.class)
    public ResponseEntity<Map<String, Object>> handleResponseStatusException(
            ResponseStatusException ex,
            HttpServletRequest request) {

        Map<String, Object> response = new HashMap<>();
        response.put("timestamp", LocalDateTime.now());
        response.put("status", ex.getStatusCode().value());
        response.put("message", ex.getReason());
        response.put("path", request.getRequestURI());
        return new ResponseEntity<>(response, ex.getStatusCode());
    }
}

• 위 메서드들에서 던진 `ResponseStatusException` 예외들은 `@RestControllerAdvice`에 있는 `@ExceptionHander`에서 공통적으로 예외처리됩니다.

 

---

 

회고

1. Repository에 있었던 기존 예외처리 로직을 전부 Service로 옮겨, Repository는 오로지 DB와 상호작용하도록 역할을 구분하였습니다.

2. userId를 검증하는 과정에서 ScheduleService에는 유저를 검증하는 로직이, ScheduleRepository에는 user와 관련된 로직이 들어가므로써, Schedule과 User가 섞이게 되었다. (리팩토링 필요)