새로운 프로젝트를 시작하며

인상 깊었던 부분

1. OAuth
현재 기획이 변경 예정이라 개발이 멈춰있는 weteam에서는 일반 로그인(jwt)만 적용시켜서 로그인, 회원가입을 진행했다.
근데 새로운 프로젝트에서는 OAuth(kakao, google)을 사용해 일반 로그인을 사용하지 않았고 security config 파일의 설정도 달랐다. 그래서 추후 OAuth부분에서 많은 공부가 될 것 같다.

2. query
repo에서 @Query 를 사용하여 select할 때 dto의 내용들을 바로 조회하는 방법을 알게됬다.
기존 프로젝트에서는 entity 조회 후 dto로 맵핑하는 프로세스였는데 앞으로는 바로 dto로 조회하여 깔끔한 코드를 작성할 수 있을 것 같다.

3. 폴더 구조
mvc로 개발을 해오면서 항상 같은 폴더 구조를 사용했다.

product
	⎿ controller
	⎿ service
	⎿ dao
	⎿ dto

member
	⎿ controller
	⎿ service
	⎿ dao
	⎿ dto
    
cart
	⎿ controller
	⎿ service
	⎿ dao
	⎿ dto

다음과 같이 도메인 구조를 써오며 바꿀 생각을 안해봤다
근데 새로운 프로젝트에서는

application
	L config
	L controller
	L handler
domain
	L schedule
		L service
		L repository
		L dto
	L user
		L service
		L repository
		L dto

위와 같이 계층형 구조와 도메인 구조를 섞은 폴더 구조를 사용했다.
새로운 폴더 구조를 사용하며 도메인만 따로 묶은 해당 구조가 매력적으로 느껴졌다
하지만 controller가 application에 가 있는 이유는 추가적으로 질의해야하는 부분이다

4. Spring, JPA에 대한 이해
다소 포괄적인 내용이지만 내가 글을 쓰는 주된 이유이자 부족함을 크게 느꼇던 주제다.
먼저 나는 update를 진행할 때
1. 대상 entity의 존재 확인 및 조회
2. entity update
3. save
순서로 진행했다
하지만 새로운 프로젝트 코드를 살펴보며 이상한 점을 발견했다.

@Transactional
    public ScheduleDto patchScheduleById(final RequestScheduleDto scheduleDto, final Long scheduleId) {
        final Schedule schedule = scheduleRepository.findById(scheduleId).orElseThrow(() -> new NotFoundException("수정할 대상을 찾을 수 없음"));

        schedule.setDate(scheduleDto.date() != null ? scheduleDto.date() : schedule.getDate());
        schedule.setAmount(scheduleDto.amount() != null ? scheduleDto.amount() : schedule.getAmount());

        return ScheduleMapper.toDto(schedule);
    }

예시 코드처럼 set method를 통해 값을 변경 후 save method를 사용 없이 바로 return하는 것을 발견했다.
테스트를 통해 update가 잘 작동하는 것을 확인했고 왜 되는지 공부하기 시작했다. 답은 select에도 트랜잭션 처리가 필요한가? 를 검색하며 알게 됬다.
참고 : https://hungseong.tistory.com/74
해당 블로그에서

영속성 컨텍스트는 Entity 조회 시 초기 상태에 대한 Snapshot을 저장한다.

트랜잭션이 Commit 될 때, 초기 상태의 정보를 가지는 Snapshot과 Entity의 상태를 비교하여 변경된 내용에 대해 update query를 생성해 쓰기 지연 저장소에 저장한다.

그 후, 일괄적으로 쓰기 지연 저장소에 저장되어 있는 SQL query를 flush 하고 데이터베이스의 트랜잭션을 Commit 함으로써 우리가 update와 같은 메서드를 사용하지 않고도 Entity의 수정이 이루어진다. 이를 변경 감지(Dirty Checking) 라고 한다.

다음과 같은 글을 읽고 아직 공부가 많이 부족하구나 생각했다. JPA책을 사놨는데 아직 못 읽고 있었는데 될 수 있으면 빨리 읽기 시작해야겠다 생각했다.
spring을 접하며 영속성 컨텍스트에 대해서도 알아본 적이 있는데 이해가 부족했다.
 

다짐