드디어 본격적으로 코드를 짜기 시작했다. 앞서 pre-project를 하면서 기본 CRUD를 작성한 경험이 크게 도움이 되었다. 기본 CRUD 작성이기에 크게 특별한 점은 없었지만, 사용한 몇 가지만 이야기하고자 한다.
- @RequiredArgsConstructor 어노테이션
생성자 주입을 할 때, 기존에는
@RestController
@RequestMapping("/example")
public class RequiredArgsConstructorControllerExample {
private final FirstService firstService;
private final SecondService secondService;
private final ThirdService thirdService;
@Autowired
public RequiredArgsConstructorControllerExample(FirstService firstService, SecondService secondService, ThirdService thirdService) {
this.firstRepository = firstRepository;
this.secondRepository = secondRepository;
this.thirdRepository = thirdRepository;
}
}와 같이 선언된 final 변수들과 필드들을 일일이 선언해줘야 했지만, 해당 어노테이션을 사용하면
@RestController
@RequiredArgsConstructor
@RequestMapping("/example")
public class RequiredArgsConstructorControllerExample {
private final FirstService firstService;
private final SecondService secondService;
private final ThirdService thirdService;
...
}다음과 같이 일일이 선언해야하는 부분들을 자동으로 생략할 수 있는 Lombok의 기능이다. 이를 사용하여 @Getter, @Setter 어노테이션들과 같이 번거로움을 없앨 수 있었다.
- 전체 리뷰 조회시 리스트 구현
전체 리뷰를 조회할 때 무한스크롤로 구현하는 걸로 FE와 이야기됐는데, 무한스크롤을 처음 사용하다보니 데이터를 리스트로 보내줘야할지 페이지네이션으로 보내줘야할지 고민됐다. 우선은 리스트로 구현하기 위해 다음과 같이 stream을 사용하여 구현해주었다.
@GetMapping
public ResponseEntity<List<ReviewDto.Response>> getReviews() {
List<Review> reviews = reviewService.findReviews();
List<ReviewDto.Response> response = reviews.stream()
.map(review -> mapper.reviewToReviewResponseDto(review))
.collect(Collectors.toList());
return new ResponseEntity<>(response, HttpStatus.OK);
}
- Optional.ofNullable().ifPresent(); 사용
리뷰를 수정할 때 리뷰 사진만 수정하는 경우, 리뷰 텍스트만 수정하는 경우, 둘 다 수정하는 경우가 각각 존재하기에 하나만 수정하여도 수정이 가능하도록 Optional.ofNullable().ifPresent()문을 사용하였다.
Optional.ofNullable(review.getReview_pic())
.ifPresent(review_pic -> findReview.setReview_pic(review_pic));
Optional.ofNullable(review.getReview_text())
.ifPresent(review_text -> findReview.setReview_text(review_text));위의 내용을 포함하여 Review에 대한 Controller, Dto, Entity, Mapper, Repository, Service 클래스 및 인터페이스를 1차 구현하였다.
이 후 이어진 오후 회의에서는 각자 진척도를 공유하고, 미용실 정보와 미용실 상세정보 간 내용이 비슷해서 미용실 정보 내용을 줄이는 등 사용자 요구사항 정의서를 다소 수정하였다. 그리고 클라이언트와 서버쪽이 같은 유효성 검사를 실시하기 위해 정규 표현식을 공유하였다.
사용자 요구사항 정의서 (ver.3)
