Conversation
+ ("/api/trainers/**" 임시 허가)
- Coordinates 내의 트레이너 위도/경도에 따른 상태를 확인하는 메서드로 변경 - TrainerAddress 도메인 클래스 정적 팩토리 메서드 제거 및 수정 - equals, hashCode 기반으로 도메인 간 비교 가능하도록 구현
- 주소 좌표 정합성, 유효성, 저장 실패 등의 예외 상태 정의 (아직 사용하지 않은 상태.)
- updateXxx() 메서드 정의
- TrainerProfileJPARepository 기본 설정 - fetch join 포함한 findDetailedProfileEntityByUserId() 구현
- 엔티티 ↔ 도메인 ↔ 요청 DTO 간 변환 로직 정의
- JPA를 통한 저장 로직 구현
- 프로필 등록 시 좌표 정합성 및 유효성 검증 포함 - 프로필 수정 시 주소 변경 여부 판단 및 정합성 검증 로직 포함
5330d69 to
bfef2b2
Compare
| /** | ||
| * 트레이너 프로필 수정 | ||
| * @param request 트레이너 프로필 요청 DTO | ||
| * @param userId 로그인 사용자 id | ||
| */ | ||
| public void updateProfile(@Valid TrainerProfileRequest request, Long userId) { |
There was a problem hiding this comment.
@Transactional 어노테이션이 필요할 것 같습니다!
There was a problem hiding this comment.
@Transactional어노테이션이 필요할 것 같습니다!
@Transactional을 클래스에 선언하신 것 같아요!
| TrainerProfile domain = TrainerProfileMapper.toDomain(entity); | ||
|
|
||
| if (domain.isInvalidContactTimePair()) { | ||
| throw new ApiException(TrainerProfileErrorCode.INVALID_CONTACT_TIME_PAIR); | ||
| } | ||
|
|
||
| if (domain.isInvalidContactTimeRange()) { | ||
| throw new ApiException(TrainerProfileErrorCode.INVALID_CONTACT_TIME_RANGE); | ||
| } |
There was a problem hiding this comment.
시간 검증을 처음에 하는 건 어떨까요? 지금 ContactTime 검증 로직이 프로필 업데이트가 끝난 후 제일 마지막에 실행되고 있어서, 예외 발생 시 이미 변경된 데이터의 일관성이 보장되지 않을 수 있습니다!
There was a problem hiding this comment.
예외 발생 시 트랜잭션이 롤백되어서 괜찮긴 한데 예외 처리의 경우 먼저 처리해주는게 좋다고 생각합니다.
예외 처리가 먼저 이루어질 경우 불필요한 DB 커넥션 점유를 방지할 수 있고, 불필요한 네트워크 I/O를 줄일 수 있으며, 트랜잭션을 최소화 할 수 있습니다.
이를 통해 네트워크 비용 감소와 동시성 성능을 향상시킬 수 있습니다.
DB 조회는 비용이 많이 발생하기 때문에 꼭 필요한 경우에만 하는게 좋습니다.
|
|
||
| TrainerAddressEntity newAddressEntity = entity.getAddress(); | ||
|
|
||
| boolean isAddressChanged = !newAddress.equals(currentAddress); |
There was a problem hiding this comment.
isAddressChanged를 TrainerAddress 클래스 내부로 캡슐화하면 재사용성이 증가하고, 호출 목적도 명확해져서 좋을 것 같아요!
| KakaoGeoResponse response = kakaoMapService.requestCoordToAddress( | ||
| newAddress.getCoordinates().getLatitude(), | ||
| newAddress.getCoordinates().getLongitude() | ||
| ); |
There was a problem hiding this comment.
메서드 파라미터로 newAddress.getCoordinates()만 받아도 괜찮을 것 같아요
| entity.updateIntro(request.getIntro()); | ||
| entity.updateProfileImg(request.getProfileImg()); | ||
| entity.updateCredit(request.getCredit()); | ||
| entity.updateContactTime(request.getContactStartTime(), request.getContactEndTime()); | ||
| entity.updateNamePublic(request.getIsNamePublic()); |
There was a problem hiding this comment.
각각의 update 메서드를 호출하기보단 하나의 update 메서드를 통해 모든 데이터를 변경하면 간편할 것 같아요!
| /** | ||
| * 트레이너 프로필 수정 | ||
| * @param request 트레이너 프로필 요청 DTO | ||
| * @param userId 로그인 사용자 id | ||
| */ | ||
| public void updateProfile(@Valid TrainerProfileRequest request, Long userId) { |
There was a problem hiding this comment.
@Transactional어노테이션이 필요할 것 같습니다!
@Transactional을 클래스에 선언하신 것 같아요!
| TrainerProfile domain = TrainerProfileMapper.toDomain(entity); | ||
|
|
||
| if (domain.isInvalidContactTimePair()) { | ||
| throw new ApiException(TrainerProfileErrorCode.INVALID_CONTACT_TIME_PAIR); | ||
| } | ||
|
|
||
| if (domain.isInvalidContactTimeRange()) { | ||
| throw new ApiException(TrainerProfileErrorCode.INVALID_CONTACT_TIME_RANGE); | ||
| } |
There was a problem hiding this comment.
예외 발생 시 트랜잭션이 롤백되어서 괜찮긴 한데 예외 처리의 경우 먼저 처리해주는게 좋다고 생각합니다.
예외 처리가 먼저 이루어질 경우 불필요한 DB 커넥션 점유를 방지할 수 있고, 불필요한 네트워크 I/O를 줄일 수 있으며, 트랜잭션을 최소화 할 수 있습니다.
이를 통해 네트워크 비용 감소와 동시성 성능을 향상시킬 수 있습니다.
DB 조회는 비용이 많이 발생하기 때문에 꼭 필요한 경우에만 하는게 좋습니다.
#️⃣연관된 이슈
📝작업 내용
스크린샷 (선택)
💬리뷰 요구사항(선택)