이전 게시물에서 말한 것 처럼 현재 모든 요구사항을 반영한 것이 아니다 '도전 기능' 에 해당하는 '세부 요구사항' 을 반영하지 않았기에 해당 요구사항들을 반영하면서 리팩토링을 진행해보려 한다. 과제 제출 전까지 진행할 리팩토링 순서는 아래와 같다.필터(인증/인가) → 유저(멤버) → 일정 → 나머지 엔티티기본적으로 적절한 클래스명, 메서드명, 변수명으로 수정 및 비즈니스 로직 수정이번 게시글에서는 '필터' 에 초점을 맞춰 리팩토링을 진행하려 한다. 이번 리팩토링으로 인해 수정된 코드는 여기서 확인이 가능하다. 1. 필터 필터를 사용하니 비즈니스 로직에서 '인증/인가' 를 분리할 수 있었다. 이번 프로젝트에서의 인증, 인가에 대한 예시는 아래와 같다.인증 : 일정을 생성하는 것은 회원(멤버)만이 가능하다..

과제의 요구사항 중 '도전 기능' 에 대한 프로젝트 반영을 끝내고(핵심 요구사항만) 요구사항 반영간 있었던 이슈에 대해서 작성해보고자 한다. 참고로 현재 '도전 기능' 의 모든 요구사항을 반영한 것은 아니다. 요구사항 중 핵심 요구사항을 반영하고 테스트한 상태라 세부 요구사항에 대한 부분은 리팩토링을 진행하면서 반영할 생각이다. 각 요구사항을 반영하며 작성한 코드는 아래의 링크를 통해 확인할 수 있다.도전 기능(Level.01 , 전체기준 Level.06)도전 기능(Level.02~03 , 전체기준 Level.07~08) 도전 기능(Level.04, 전체기준 Level.09) 1. JWT 검증시 발생하는 예외 강의 및 검색을 통해 JWT 에 대한 구현을 진행하면서 JWT 검증에 아래와 같은 코드를 참고해..

Lv.4 요구사항은 단순하게 보면 '유저' 정보를 갖는 엔티티를 추가하는 것이다. 하지만 세부 요구사항을 보면 'N : M' 관계에 대해 더 집중해야 함을 예상할 수 있었다. 1. ERD간략하게 요구사항을 정리하면 '유저' 엔티티가 추가되며 '일정' 엔티티는 작성자에 대한 정보로 '유저' 엔티티의 식별자 값을 가져야 한다. 더불어 일정 생성시 작성자(유저)는 일정을 관리(담당)해 줄 '관리자' 를 설정할 수 있어야 한다.한 명의 유저는 여러개의 일정을 작성 가능 - "유저 엔티티 : 일정 엔티티 = 1 : N"하나의 일정에 여러명의 일정 관리자(=유저)를 지정 가능 - "일정 엔티티 : 유저 엔티티 = 1 : N"즉, 유저 엔티티와 일정 엔티티는 'N : M(다대다)' 관계를 맺어야 하는 것이다. 솔직히..

이번에는 '1 : N 관계' 에서의 '전체(목록) 조회를 구현하면서 겪은 기묘한 모험담(?) 을 기록해보려 한다. 이번 뿐만 아니라 이후 프로젝트 또는 실무에서도 충분히 겪을 수 있는 상황이라 생각해 기록하게 되었다. 이번에 작성한 코드는 여기서 확인할 수 있다. 먼저 현재 프로젝트는 'Spring Data JPA' 를 활용한 프로젝트이기에 최대한 'JPA' 를 활용하는 목적을 가지고 있다. 프로젝트 진행 중 'Lv.3 요구사항 - 페이지네이션' 을 반영하게 되며 문제가 연이어 터지게 되었다. 여기서 말하는 요구사항은 '일정 엔티티' 가 '댓글 엔티티' 와 '1 : N' 관계를 가져야하고, '일정' 을 전체(목록) 조회를 할 때 일정의 정보와 일정이 갖는 댓글 엔티티 개수를 반환해야 한다는 내용이다. 또..

댓글 CRUD 에 대한 구현을 진행한 후 진행한 API 테스트를 기록하기 위해 작성한다. 또한 요구사항에 명시된 '영속성 전이' 에 대한 부분도 간략하게 나마 정리해볼 생각이다. 이번에 작성한 코드는 여기서 확인할 수 있다. 1. 댓글 생성  댓글 작성시 쿼리 파라미터와 RequestBody 로 요청 파라미터를 받도록 구현했다. 쿼리 파라미터에는 댓글을 작성할 일정의 'id' 값이 RequestBody 에는 작성할 댓글의 '본문(body), 작성자명(author)' 정보가 담겨있다. 정상 요청을 하면 '201 Created' 응답과 생성된 댓글의 정보가 반환된다. 요청 파라미터가 유효하지 않을 경우 아래와 같은 응답과 예외 정보를 반환한다. '(1)' 의 경우 존재하지 않는 일정에 댓글을 작성하는 경우이..

'일정 수정 및 삭제' 에 대한 구현 후 진행한 API 테스트 기록을 남겨본다. 단순히 기록뿐만 아니라 진행 당시 느낀 '이후에 염두해야 할 부분' 또한 남겨본다. 구현을 위해 작성한 코드는 여기서 확인 가능하다. 1. 일정 수정  Query String Parameter 로 'scheduleId' 를 RequestBody 로 'title, body' 정보를 요청 파라미터로 전달하면 해당되는 일정을 조회해 해당 일정의 정보를 수정 DB 에 반영한다. 이 부분을 구현하면서 왜 다수의 개발자들이 '수정' 이란 기능을 수행후 변경 값을 반환하지 않는지 약간이나마 이해할 수 있었다. 맨 처음에는 수정 정보를 RequestBody 로 전달 받아 요청에 해당되는 '일정' Entity 의 필드를 수정하고 '@Tran..