목차
1. 파일 구조의 이해
2. 비밀번호의 무효화
3. entity, dto의 제약조건은 왜 오류가 다를까?
4. 총체적 난국
1번 트러블 슈팅
- 모놀리틱 아키텍처(때려박기용)
하나의 애플리케이션(하나의 코드베이스/배포 단위) 안에 기능들이 같이 있음
- 마이크로서비스 아키텍처(MSA, 나누기, 대규모용)
기능을 서비스 단위로 쪼개서 각자 따로 배포/확장하는 구조.
2. 비밀번호의 무효화
- User/entity에 제약 조건을 걸었는데 비밀번호가 8자리 미만으로 입력을 하여도 통과가 되는 경우가 발생했다.
- 이유가 뭐니 찾아보니 우리는 암호화를 작성 하였는데 Service에서 그 암호화를 거쳐가다 보니 비밀번호가 암호화된 상태로 통과를 하는 것이다. 그러니까 무조건 20자는 족히 넘어갈 것이다.
2. 해결 방법
- 따라서 해결 방법은 entity가 아닌 dto에 제약 조건을 걸어 해결 했다.
3. entity, dto의 제약조건은 왜 오류가 다를까?
- entity에 걸었을 때
-
왜 여기서는 500/ ConstraintViolationException: 으로 나올까
-
밑에는 dto에 걸었을 때
- 여기서는 400/ MethodArgumentNotValidException 으로 나온다.
3. 궁금증 해결 (help. 조용석 튜터님)
-
DTO에 @Valid를 걸면 요청 바인딩 단계(Controller 들어오기 전) 에서 검증이 실행되어 MethodArgumentNotValidException이 발생하고, 보통 클라이언트 입력 오류로 분류되어 400으로 내려간다.
-
Entity에 제약을 걸면 Repository save/flush, 트랜잭션 커밋 직전(JPA/Hibernate 영속화 단계) 에서 검증이 실행되어 ConstraintViolationException(또는 TransactionSystemException에 래핑)이 발생한다.
-
이 단계에서 터진 예외는 스프링 기본 매핑상 “요청 검증 실패”가 아니라 “서버 내부 처리/트랜잭션 실패”로 취급되기 쉬워 500(Internal Server Error) 로 보이는 경우가 많다.
-
결론: 객체가 달라서라기보다 검증이 발생하는 레이어(전 단계: Web / 후 단계: JPA) 와 예외 처리(매핑) 대상이 다르기 때문이다.
4. 총체적 난국
회원가입을 하고 로그인을 해야 스케줄, 게시물이 달려야 하는데 회원가입만 해도 다 작성 되는 현상 발생
해결은 했지만 너무 많은 작업으로 인한 내용 작성 불가
취준생