Open limseulki opened 1 year ago
try/catch와 예외를 throw하는 건 구분해서 이해하시면 좋을 것 같아요. try/catch는 throw된 예외를 catch해서 이후 처리한다고 보시면 될 것 같구요. throw는 정상적으로 로직을 완료하지 못할 때, exception을 던져서 로직을 어떤 이유로 완료하지 못했다는 것도 함께 표현할 수 있어요. 예를 들어 비밀번호가 틀렸을 때 클라이언트에게 '비밀번호가 틀려서 정상적으로 동작을 완료하지 못했다'라는 걸 알려주는 거죠. 이런 맥락에서 본다면 비밀번호가 틀린 상황도 예외 발생으로 볼 수 있고, throw를 해주시면 될 것 같아요. 이 throw된 에러를 어떻게 처리할지는 spring 예외처리 등의 키워드를 찾아보시면 좋을 것 같네요!
트랜젝션은 특히 db에서 데이터에 변경이 있는 경우(수정이나 삭제), 정상적으로 끝나 커밋하거나 혹은 에러가 발생했을 때 롤백 처리를 하기 위해 중요하게 사용됩니다! 수정, 삭제의 경우 특히 주의해서 사용해야해요. @Transactional(readonly = true)
는 잘 사용하면 조회 속도를 향상시킬 수 있습니다. 관련해서 영속성 컨텍스트를 더 공부해보시면 좋을 것 같아요. 코드 중에 saveAndFlush
가 사용된 경우가 있는데 save
와 같이 찾아보세요.
controller에서는 항상 dto를 사용하시는게 좋습니다! password처럼 값을 하나만 경우에는 dto를 만들지 그냥 바로 값을 받을지 고민해보시면 좋을 것 같아요. request/response의 경우 개발 도중(특히 클라이언트와 협업 중에 )수정이 발생하기 쉬운 편이에요. 이 경우에 dto가 있는지 없는지, dto를 공통으로 사용하는지, 아닌지도 영향을 줄 수 있습니다. 앞으로 과제/팀 협업 하시면서 dto도 계속 고민해보시면 좋을 것 같아요.
삭제, 수정 부분에서 비밀번호 불일치 예외를 throw로 던져주었습니다. try-catch를 사용하려다 비밀번호를 가져오는 작업에서 예외가 발생하는 건 아니라서 throw로 해주었는데, 더 나은 방법이 있는지 피드백 부탁 드려요.
@Transactional 어노테이션은 클래스나 메서드에 붙여 해당 범위가 트랜잭션이 되도록 보장해 주는 것으로 알고 있습니다. 연산 도중 실패할 경우 변경 사항이 commit되지 않고, rollback하게 되는 특성이 있어 CRUD 작업 중, 삭제를 제외하고 붙여주었습니다. 그리고 조회하는 부분은 read only 옵션을 두어 Read 작업만 진행될 수 있도록 수정했습니다. Transactional을 적절하게 사용한 게 맞는 지 궁금합니다.
Delete를 위하여 password만 받아오는 Dto를 별도로 생성해주었습니다.