캡슐화 연습4 질문 있습니다.
개선 후 예제에서 mem.verifyEmail() 시도 후 수정사항을 DB에 반영하고 있습니다.
궁금한 점은 DB 반영 완료 후 verifyEmail() 내부의 this.verificationEmailStatus = 2를 하는 게 맞지 않는가 궁금합니다.
이유는 DB 반영 전에 this.verificationEmailStatus = 2를 진행 후 DB 반영을 한다면, 만약 DB 반영 실패 시 다시 verificationEmailStatus를 2가 아닌 값으로 바꿔주는 작업이 필요로 해 보입니다.
만약 DB 반영 실패를 검출하지 못한 경우 this.verificationEmailStatus를 이전 값으로 바꿔주지 못하고 DB 혹은 서버가 죽은 경우, 다음 verifyEmail을 시도 시 this.verificationEmailStatus는 2가 된 상태인데 DB에는 반영이 되지 않은 상태가 존재할 수 있다고 생각이 듭니다.
혹시 이 경우 좋은 해답이 존재하는 지 궁금합니다.
이상입니다.
감사합니다.
回答 2
1
코드를 다시 보죠.
public void verifyEmail(String token) {
Member mem = findByToken(token);
if (mem == null)
throw new BadTokenException();
mem.verifyEmail();
// … 수정사항 DB 반영
}이 코드에서 DB 연동에 문제가 있으면 verifyEmail(String token) 메서드는 트랜잭션을 롤백할 겁니다. 재시도를 하는 단위도 mem.verifyEmail()이 아니고, verifyEmail(String token) 메서드가 되구요.
설사 DB 연동 실패를 제대로 처리하지 못하더라도 verifyEmail(String token) 메서드를 다음에 다시 실행하면 findByToken()은 DB에 저장된 데이터를 기준으로 Member를 조회하게 됩니다. 즉 verificationEmailStatus는 이메일 인증 전 상태를 의미하는 값을 갖고 있죠.
그래서 수정사항을 DB에 반영할 때 실패했을 때 다시 Member 객체의 verificationEmailStatus 필드 값을 되돌리는 작업은 필요하지 않습니다.
추상화 예제의 추상화하지 않은 구현 부분에서 질문있습니다.
0
446
1
캡슐화 하는 이유에 대해서
2
757
1
캡슐화 연습 2번
0
370
1
추상화 예제에서 추상 클래스를 사용하지 않고 인터페이스를 사용하신 이유가 궁금합니다.
0
269
2
캡슐화 예제 4 질문입니다.
0
272
1
범균님 안녕하세요 강의 수강중 궁금한점이 있어 질문 남겨 봅니다.
0
366
1
캡슐화 질문
0
322
1
DIP 관련해서 궁금한게 있습니다.
0
260
1
기능 분리 기준에 대한 질문이 있습니다.
1
361
2
서로 다른 구현 추상화에 대해서 질문이 있습니다.
2
369
2
의존 주입 예제 관련 질문입니다.
1
257
1
상속 재활용 단점 중 상위 클래스 변경 어려움에 대해서 질문이 있습니다.
1
316
2
의존하는 대상이 많을 때 질문 드립니다.
0
265
1
추상화를 따라서 코딩해볼 수 있는 예제가 있을까요?
0
451
1
콘크리트 클래스를 직접 사용하는 경우 & NotifierFactory 관련 질문드립니다
1
277
1
Demeter's Law 설명이 잘 이해가 안갔습니다 ㅠㅠ
1
287
1
혹시 강의를 듣고 필기한 내용을 정리해서 블로그에 올려도 될까요?
0
359
2
캡슐화 예제 질문드립니다
0
546
4
DIP
1
375
3
예제코드는 따로 없나요?
1
231
0
NotifierFactory 를 또 추상화 한 이유가 궁금합니다
0
198
1
특정 클라우드에서 예외적으로 특정기능을 제공하지 않는 경우
6
214
1
상속과 조합 문의드립니다
1
267
1
강의자료를 받아볼수 있나요?
1
282
2