TIL - 21.01.28
페이징 완성도
Pageable 구현체
-
기본 생성자가 있다면 오버로딩을 잘 활용하자
- 생성자에서 반드시 Validation 처리해줄 것.
- 음수값, 최솟값등 체크해주자
final
로 만들어서 수정 불가한 Immutable 로 만들기
실수하는 것 - Validation 체크
input값이 이상적으로 들어오는 케이스만 고려하고 있다.
offset과 limit이 숫자가 아닌 문자가 들어왔다면?
문자를 숫자를 만드려다가 NumberFormatException이 발생한다. request가 페이징 API 쿼리로 들어오지도 않는다. ⇒ 이런식의 처리는 좋지않다. 기본값을 셋팅해놨으니깐 적절한 값이 들어오지 않은 경우 에러가 아닌 Default Value로 처리해주도록 하자.
fallbackPageable
supportsParameter()
구현이 중요
- 해당 타입이 맞는지 확인할 때,
-
equals
로 하는 경우 생길 수 있는 문제인터페이스가 아니라
구체 타입
이 나온다면 제대로 처리가 되지 않는다. -
isAssignableFrom()
으로 처리해주자상속관계에 있는 것도 확인할 수 있도록 처리해줘야 한다.
항상 생각할 것
- 외부의 입력값을 절대로 믿지말고 Validation을 하자
- 모든 가능한 예외사항을 고려해서 코드를 만들자. 의도하지 않은 에러를 만들지 말자
- 구체타입을 쓰는 것보다 인터페이스를 써서 많이 처리한다.
좋아요 API
적어도 JOIN은 잘 작성할 수 있어야한다.
스칼라 서브 쿼리 문제점
추출되는 데이터가 적을(수십개??) 경우에는 select 절안에 select 쿼리를 또 적어도 되겠지만, 스칼라쿼리로 조회되는 데이터양이 많다면 성능에 문제가 있을 수 있다.
주의할 점 - 놓칠 수 있는 Validation
POST는 나와 친구의 POST만 읽을 수 있다.
(로그인한 유저가 1일 때,), /user/2/post/33
POST를 읽을 수 있을까? ⇒ 실패
33번 게시물이 2번 유저의 글이 아니므로, 이것을 체크하는 where 조건을 작성해줘야한다.
voter에서는 /user/2
까지만 체크하므로 쿼리에서 2번 유저가 33번 게시물을 작성한 것이 맞는지를 체크해줘야하는 것이다.