일정관리 API 구현 V2
20250108~09
검증과 예외처리의 구현
(Validation 사용 및 스프링 예외처리 본격 활용)(V1도 하긴 했었다)세션 사용 및 기본적인 암호화 (JWT 와 시큐리티 사용은 추후)
페이징 조회 추가해보기
이 세 요소가 추가적으로 제공 되었다
그냥 만들기 싫어서 나름 알고는 있는데 안 써본 개념을 사용해본다고
이것저것 가져다 붙였는데 생각보다 시간을 많이 쓰고 있다
중간에 간과한 사항이 하나 있는데, MVC 의 실행 순서다
세션 사용을 하니 나름의 미허용 접근을 차단하려고
(미 로그인에서 CRUD 일부 API가 동작하는 등)
세션 체킹을 Aspect 로 도입했는데 아무리해도 원하는 처리가 안되었다
그저 명시된 세션을 못찾는다는 에러만
커스텀 익셉션 핸들러의 마지막 Exception.class 처리에 걸려서 나오고 있었다
서비스단에서 세션을 갖고와서 처리하는 건 코드를 너무 길어지게 하고
아예 원치 않기도 해서 (7계층 적으로 전혀 무관한 단에서 처리하는 게 맞나..?)
컨트롤러에서 제어를 원했는데 왜 안되는건지 보니.. MVC 실행 순서가 문제였다
현재 세션을 파라미터로 바인딩 해서 사용하는데 Aspect 가 실행 순서상 뒤였다
인터셉터를 활용해서 커스텀 어노테이션을 붙였을 때만 작동하도록 고쳤다
인터셉터는 스프링 프레임워크 사용 경험에서
몇번 써봤었는데 기억이 잘 안나서 11일에 다시 포스팅 해야겠다
20250110
확실히 양방향이건 단방향이건 간에..
둘 다 사용해서 처리해보아도 맘에 안들어졌다
결과를 쿼리 메서드를 사용해서 꺼내오는 과정에서
주인이 아닌 테이블에서의 N+1 조회 문제는 생각보다 자주 발생하는 것 같다
JPQL로 직접 조인 매핑해줬다, 점점 JPA가 생각보다 괘씸해진다
또 프로젝션 하기 위해 별도의 DTO 인터페이스가 생기는 점이
싫은데 처음부터 응답 DTO를 프로젝션 하지 않는 한 방법이 없는 것 같다
코드의 통일성을 나름 지키기 위해 그냥 인터페이스 DTO 프로젝션으로 처리했다
페이징 처리는 생각보다는 간단했는데, 이거 하나로 다 되는건가 싶다
예전에 비슷한 처리를 할 때 뭔가 했던 방식이 간단하지 않았던 건지
기억이 날듯말듯 해서 우선 JPA 페이징 처리부터 되짚어 정리해야겠다
여하튼 자꾸 핫픽스로 고쳐야 되는 버그들도.. 적당히 마무리 된 것 같다
설계를 못하는 탓인건지 되짚어 보면 의도하지 않게 버그가 많이 나오는데
이 부분은 충분히 처음부터 생각을 좀 하고 코드를 만드는 버릇을 들여야 할 것 같다
아무 생각없이 로그인에 사용하는 이메일을 수정시엔
중복값으로 처리되게 아무 장치 없이 해놓지 않는 등.. 좀 서두른 코드가 많이 나왔다