인프런 커뮤니티 질문&답변

수강생으로서 저의 의견입니다. Repository의 구현체에 의존하지 않도록 하신 것으로 보입니다. 만약 더티 체킹을 이용한다면 그건 JPA에 강결합되어 있는 상태라고 판단할 수 있습니다. 또한 더티 체킹을 사용하려면 도메인 객체에 @Entity를 비롯한 JPA 관련 코드가 추가해야 합니다. 이는 도메인 객체가 외부 의존성과 결합되어 있기 때문에 깨끗한 도메인 객체가 아닙니다. 그래서 강사님도 도메인과 DB 엔티티를 분리해서 작성하고 더티 체킹이 아닌 Repository.save()를 사용하신 것으로 생각됩니다.

안녕하세요. 답변이 늦었습니다.

@jeidiiy님이 의견 남겨주셨네요. 감사합니다. 게다가 하고 싶은 말을 다 대신 해주셔서 추가로 답변해 드릴게 없네요. ㅎ;; :)

조금만 더 덧붙이자면, 저의 짧은 경험에 근거하면 도메인 모델과 영속성 객체의 의존성을 완전히 제거하면서도 더티 체킹 기능을 살리는 방법은 없지 않을까 싶습니다. 애초에 JPA의 특정 기능을 활용해서 애플리케이션을 만들겠다는 건데… 전제 자체가 JPA에 강결합이 될 수 밖에 없다고 생각이 되고요. (혹시라도 나중에 더 괜찮은 사용 사례가 있거나 만들게 되면 공유해주세요!)

관련해서 비슷한 답변을 아래와 같이 미리 한 적이 있기 때문에 아래 링크를 첨부합니다.

• https://www.inflearn.com/questions/945855/comment/280701

• https://www.inflearn.com/questions/978220

이미 해결된 질문인 것 같지만 미약하게나마 더 도움이 되셨길 바라며 좋은 하루되세요!

안녕하세요, 인프런 AI 인턴이에요. 이전에 도메인 모델과 영속성 객체를 구분하는 리팩토링에 대해서 진행하셨다고 말씀하셨는데요. 더티체킹은 JPA에서 변경된 엔티티를 자동으로 감지하여 데이터베이스에 업데이트를 수행하는 기능입니다.

리팩토링을 통해 도메인 모델과 영속성 객체의 의존성을 제거하고, save 메서드를 호출하여 엔티티를 저장하는 방식을 사용하셨다면, 더티체킹 기능을 사용하지 않는 것으로 보입니다. 이는 일반적으로 JPA의 영속성 컨텍스트가 변경된 엔티티를 추적하고, 변경 내역을 데이터베이스에 자동으로 반영하는 기능을 사용하지 않는 것을 의미합니다.

이 방식은 개발자가 직접 save 메서드를 호출하여 엔티티를 저장하므로, 변경된 엔티티를 추적하고 데이터베이스에 반영하는 작업을 개발자가 수동으로 처리해야 한다는 점을 고려하셔야 합니다. 이를 통해 더 세밀한 제어를 할 수 있을 뿐 아니라, JPA의 내부 동작 방식을 명확하게 이해할 수 있습니다.

더티체킹과 save 메서드 호출 방식은 각각의 장단점이 있으므로, 프로젝트에 맞게 선택해야 합니다. 도메인 모델과 영속성 객체의 의존성을 제거하고, 더티체킹 기능을 사용하지 않는 방식이 옳은 선택인지는 프로젝트의 요구사항과 개발자의 판단에 따라 다를 수 있습니다. 자세한 내용은 해당 강의의 내용을 참고하시거나, JPA 관련 자료를 참고하시면 도움이 될 것 같아요. 이해에 도움이 되셨나요? 더 궁금한 점이 있다면 언제든지 물어보세요!