작성
·
82
0
안녕하세요! 강의를 듣고, 궁금증이 생겨서 찾아보던 중 명확한 답을 얻지 못해서 질문드립니다!.
첫째로 DIP에 관련된 질문입니다.
회원가입과 비밀번호 암호화 강의 중 "DTO를 서비스 계층으로 바로 넘기는 게 좋지 않다"고 하셔서 궁금증을 가지고 찾아보던 중에
이 질문을 보고 관련 내용들을 찾아봤지만, 궁금증을 완전히 해결하지 못해서 질문드립니다.
public class Auth ControllerAuthController {
private final Auth ServiceAuthService auth ServiceauthService;
private final ?AppConfig ?appConfig;
@Post MappingPostMapping("/APIapi/auth/signup")
public void signup(@Request BodyRequestBody Signup signup) {
auth ServiceauthService. signup(signup).signup(signup);
}
}
위와 같은 코드가 있을때 DIP를 지키면서 코딩한다면 단순히 Controller -> Service로 넘기기 위한 전달용 DTO를 만들어서 사용하시는지 궁금합니다.
두 번째로 @transactional에 관한 질문입니다.
데이터의 수정 및 변동이 있는 부분에는 @transactional을 붙이는 것이 좋다고 들어왔습니다. 그런데 강의의 코드에서는 붙인 부분과 안 붙인 부분이 나뉘는데 특별한 이유가 있을까요?
또 한 readonly 속성은 데이터를 읽기만 하는 부분에서는 성능에 도움이 된다고 들었습니다.
위의 내용들로 데이터의 변동이 일어나는 부분엔 @transactional을 붙이고, 읽어오기만 하는 부분에는 readonly 속성을 습관적으로 붙여왔는데 호돌맨님 께서는 @transactional을 사용하는 기준(?) 같은게 있으실까요?
긴 질문 읽어주셔서 감사합니다 :)
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. addvd님.
질문하신 DIP와 @Transactional에 관해 설명드리겠습니다.
DIP는 객체 지향 설계 원칙 중 하나로, 고수준 모듈이 저수준 모듈에 의존하지 않고 추상화에 의존해야 한다는 원칙입니다. 따라서, 컨트롤러에서 서비스로 넘어갈 때 DTO를 사용한다면, 서비스는 DTO의 내부 구현에 의존하지 않도록 설계하는 것이 중요합니다.
호돌맨님께서는 DTO를 서비스 계층으로 바로 넘기는 것이 좋지 않다는 점을, DTO가 서비스 계층의 건전한 인터페이스를 해칠 수 있기 때문이라고 말씀하셨습니다. 이에 대한 대안으로는 “어댑터” 또는 “변환자” 패턴을 도입하여, 필요하다면 DTO를 도메인 객체로 변환한 후 서비스 계층에 넘기는 방식이 있습니다.
자세한 내용은 호돌맨님의 답변을 참고하세요:
DTO 변환 관련 질문
@Transactional
은 JPA에서 트랜잭션을 관리하는데 사용됩니다. 일반적으로 데이터의 상태가 변경되는 메소드에 이 어노테이션을 붙이는 것이 좋습니다.
데이터 변경(쓰기): 데이터 변경을 수반하는 메소드에서는 기본적인 @Transactional
을 사용하여, 모든 데이터 수정 작업이 원자성을 가지도록 보장합니다. 즉, 실패 시 모든 변경사항을 롤백할 수 있게 합니다.
데이터 조회(읽기): 데이터 조회만 하는 메소드에는 readOnly = true
속성을 사용할 수 있습니다. 이는 JPA가 성능 최적화를 위해 더티 체킹을 하지 않게 해주므로 성능에 유리할 수 있습니다.
강의에서 왜 붙인 부분과 안 붙인 부분이 나뉘는가에 대한 구체적인 이유는 각 메소드의 기능과 요구사항에 따라 달라질 수 있습니다. 호돌맨님의 강의 내에서 특정한 이유가 있거나 강의 목표에 맞추어 다르게 처리했을 수 있습니다.
또한, @Transactional
적용의 기준은 코드의 복잡성, 데이터 신뢰성 필요성, 퍼포먼스 요구사항 등을 고려하여 결정하는 것이 좋습니다.
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.