20240815 본캠프 24일차 TIL

본캠프 20일차 내용 간단요약

✔️과제 마무리

 

---

오늘의 요약

주말에도 나와버린 나야나 나야나~..

 

헉..! 지금이 과제를 마무리하기 딱 좋은시간이자낭!

아주 렄키비키잔앙!

---

 

과제

7단계

설명
많은 양의 데이터를 효율적으로 표시하기 위해 데이터를 여러 페이지로 나눕니다. 
페이지 번호와 페이지 크기를 쿼리 파라미터로 전달하여 요청하는 항목을 나타냅니다.
전달받은 페이지 번호와 크기를 기준으로 쿼리를 작성하여 필요한 데이터만을 조회하고 반환합니다.
조건
등록된 일정 목록을 페이지 번호와 크기를 기준으로 모두 조회합니다. 
조회한 일정 목록에는 담당자 이름이 포함되어 있습니다.
범위를 넘어선 페이지를 요청하는 경우 빈 배열을 반환합니다.

 

참고자료!

https://velog.io/@yoonuk/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-Pagination%EC%9D%84-%EA%B5%AC%ED%98%84%ED%95%98%EB%8A%94-SQL

[데이터베이스] Pagination을 구현하는 SQL

 

페이지네이션을 구현해야한다!

은근 간편하게 구현해야하는법이 있더라

복잡하게 생각하지말기!

 

    public List<ScheduleResponseDto> readScheduleList(@RequestParam(required = false) Long managerId,
                                           @RequestParam(required = false) String date,
                                                      @RequestParam(required = false) Integer pageNumber,
                                                      @RequestParam(required = false) Integer pageSize)

 

일단 받는 파라미터를 바꿔준다

 페이지넘버와 페이지 사이즈를 받아준다

        if(pageNumber!=null)
        {
            query.append(" AND s.scheduleId <= ? AND s.scheduleId > ? ORDER BY s.scheduleId DESC ");
            queryArgs.add(pageSize*pageNumber);
            queryArgs.add((pageNumber-1) * pageSize);
        }

 

그리고 위 처럼 해당 id를 정렬한 후, 스케쥴의 범위가 페이지 사이즈만큼만 받아오게 하면되는것!

 

8단계

예외 상황에 대한 처리를 위해 HTTP 상태 코드(링크)와 에러 메시지를 포함한 정보를 사용하여 예외를 관리할 수 있습니다.
필요에 따라 사용자 정의 예외 클래스를 생성하여 예외 처리를 수행할 수 있습니다.
c를 활용하여 공통 예외 처리를 구현할 수도 있습니다.
예외가 발생할 경우 적절한 HTTP 상태 코드와 함께 사용자에게 메시지를 전달하여 상황을 관리합니다.
조건
수정, 삭제 시 요청할 때 보내는 비밀번호가 일치하지 않을 때 예외가 발생합니다.
선택한 일정 정보를 조회할 수 없을 때 예외가 발생합니다.
잘못된 정보로 조회하려고 할 때 
이미 삭제된 정보를 조회하려고 할 때

 

참고자료! 

https://cs-ssupport.tistory.com/496

[Spring] API 예외 처리

 

아래와 같이 구현했다

    /**
     *
     * @param ex
     * @return
     */
    @ExceptionHandler(IndexOutOfBoundsException.class)
    public ResponseEntity<Map<String, Object>> handleIndexOutOfBoundsException(IndexOutOfBoundsException ex) {
        Map<String, Object> errorAttributes = new HashMap<>();
        errorAttributes.put("에러 내용", "해당 내용이 없습니다");
        errorAttributes.put("에러 메세지", ex.getMessage());
        errorAttributes.put("상태 코드", HttpStatus.INTERNAL_SERVER_ERROR.value());

        return new ResponseEntity<>(errorAttributes, HttpStatus.INTERNAL_SERVER_ERROR);
    }

 

생각해보니, 상태코드는 자연스럽게 못받나? 싶었는데

다른분한테도 물어보니 여러개 뺴야한다고 하더라 ㅇㅇ..

 

 

익셉션 패키지를 만들어 정해놨지만

크흠.. 저걸 써야하는 방법을 알기힘들군

이래서 일단 패스해놨다

 

참고자료 

https://ymkmoon.github.io/Java-02-Status-Code/#google_vignette

[Java] Http Status Code

https://cs-ssupport.tistory.com/496

[Spring] API 예외 처리

 

구현9

유효성 검사
잘못된 입력이나 요청을 미리 방지할 수 있습니다.
데이터의 무결성을 보장하고 애플리케이션의 예측 가능성을 높여줍니다.
Spring에서 제공하는 @Valid 어노테이션을 이용할 수 있습니다.
조건
할일은 최대 200자 이내로 제한, 필수값 처리
비밀번호는 필수값 처리
담당자의 이메일 정보가 형식에 맞는지 확인 

 

https://jyami.tistory.com/55

@Valid 를 이용해 @RequestBody 객체 검증하기

 

생각보다 쉬웠던 문제

사실 쉽게 만들어준 위의 링크분께 감사드립니다 (_ _)

 

public ManagerResponseDto addManager(@Valid @RequestBody ManagerRequestDto managerRequestDto)

dto에 @Valid어노테이션을 달아 검증 로직을 들어간다

@Email
    private String email;

 

이메일에 이메일 형식을 지키게 어노테이션을 한다

자세히보니 살짝 아쉬운 이메일 형식

 별게 다 들어가는것을 볼  수 있다

 

그래서 또 참고한 자료..

 

https://velog.io/@mj3242/Spring%EC%97%90%EC%84%9C-%EC%9D%B4%EB%A9%94%EC%9D%BC%EC%9D%84-%EA%B2%80%EC%A6%9D%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95

Spring에서 이메일을 검증하는 방법

 

@Pattern(regexp = "^(?=.{1,64}@)[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)*@[^-][A-Za-z0-9-]+(\\.[A-Za-z0-9-]+)*(\\.[A-Za-z]{2,})$"
            , message = "이메일 형식은 ~@~.~를 지켜주세요.")
    private String email;

 

이메일을 패턴으로 변경하였다

어휴 정규식 잘 짜는사람 보면 부럽달까..

 

@Size(min = 1, max = 200)
    private String contents;
    @NotEmpty
    private String password;

 

size 어노테이션을 이용해서 1~200글자만 받게했다

딱히 테스트할게없어서 골목식당 보는거.... 적었숨..

 

---

과제를 제출하기 전

과제를 제출하기전에 질문사항이 있길래 정리해본다

 

수정, 삭제 API의 request를 어떤 방식으로 사용 하셨나요? (param, query, body)

수정 api

 @PatchMapping("/{id}")
    public ScheduleResponseDto updateSchedule(@PathVariable Long id, @RequestBody ScheduleRequestDto scheduleRequestDto)
    {
        ScheduleService scheduleService = new ScheduleService(jdbcTemplate);
        return scheduleService.updateSchedule(id, scheduleRequestDto);
    }

수정api는 id를 파라미터로 받고 수정할 정보를 body로 받았다.

 

@DeleteMapping("/{id}")
public Long deleteSchedule(@PathVariable Long id, @RequestBody ScheduleRequestDto scheduleRequestDto)
{
    ScheduleService scheduleService = new ScheduleService(jdbcTemplate);
    return scheduleService.deleteSchedule(id, scheduleRequestDto);
}

삭제 api또한 id를 파라미터로 받았으며, 비밀번호를 body로 받았다.

 

RESTful한 API를 설계하셨나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요? 구체적으로 답변해주세요.

 

1. URI는 정보의 자원을 표현해야한다

위 내용은 튜터님께 피드백 받은데로 동사를 제거하고 명사를 사용했다

2. 자원에 대한 행위는 GET POST PUT DELETE 어노테이션을 사용하여 구분하였다

GET으로 리소스를 조회하며

POST로 자원을 생성하며

PATCH로 자원을 수정하며

DELETE로 자원을 삭제한다

 

스프링이 정말 처음이라 RESTFUL한 설계를 구현했다고는 솔직히 말을 하지 못하겠다

다만 위 원칙을 지키고, 지키려고 수정은했다

 

적절한 관심사 분리를 적용하셨나요? (Controller, Service, Repository)

Controller에서는 http요청을 받아서 service로 전달을하고 다시 반환하는 방식으로 설계를 하였다

service에서는 비즈니스로직과 함께 데이터처리를 담당하였다

Repository에서는 데이터베이스와의 상호작용을 한것같다

 

과제를 하면서 어려웠던 점이 있었다면 무엇인가요?

필수 구현 과제는 어느정도 강의자료를 보면서 따라갈 수 있었다

다만, 아직 스프링에 대한 개념이 적어서 내 코드가 적절한 원칙을 따르며 설계를 하고 있는가 (최소한 강의에서 배운 내용을 지키고 있는가)에 대한 스스로의 물음에 대한 답변은 돌아오지 않았다.. 위에 대한 답변만 보더라도 확신이 가지않는다.

이건 실력이 늘고 묻고 정보를 찾는 과정에서 자연스럽게 해소가 된다고 생각한다, 아직은 스프링을 접해본지 1주밖에 되지 않았기때문에 낯설었다는 점에서 어려웠다.

어려웠지만 재밌는 한주였다