작성
·
147
0
여기 강의 섹션2.API개발 기본-회원조회 강의에서는 @jsonIgnore 사용은 최악이라고 하셧거든요. 이유도 납득갔습니다.
그런데,
섹션4.API개발 고급-간단주문 조회 V1에서는 최악이라고 하셨던 @jsonIgnore를 쓰시는데 . 어떻게 받아들이면될까요??최악이라고 하셨는데 ,나중에 사용하셔서 학습자입장에서 띠용했습니다.
답변 2
0
안녕하세요. 윤재윤님, 공식 서포터즈 y2gcoder입니다.
API 개발 고급 - 지연 로딩과 조회 성능 최적화 > 간단한 주문 조회 V1: 엔티티를 직접 노출
을 학습하고 계신 것으로 보입니다!
본 강의는 강의 소개에서도 보실 수 있듯이 단계별로 조회 API를 튜닝하는 방식을 취하고 있습니다 🙂
그래서 제일 첫단계에서는 그렇게 할 수 있지만 추천하지 않는 방식을 먼저 보여드리고 있습니다!
강의 자료에도 좋지 않다고 명시하고 있는 점, 그럼에도 이렇게 하면 사용이 가능한 방식이기 때문에 소개드리고 있는 점 참고해주시면 감사하겠습니다!
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. 윤재윤님,
스프링 부트와 JPA 통합 강의에서 @JsonIgnore
사용을 언급하신 부분에 대한 혼란에 대해 이해합니다. 강의에서 @JsonIgnore
를 “최악”이라고 언급한 이유는 일반적으로 엔티티를 그대로 노출함으로써 발생할 수 있는 여러 가지 문제점 때문입니다. 이는 특히 연관 관계가 복잡한 엔티티 구조에서 순환 참조로 인한 이슈, 즉시 로딩과 지연 로딩의 문제 등을 포함합니다. 순환 참조는 객체 간에 서로를 계속 참조하는 상황이 발생할 때 발생하며, 이는 JSON 변환 시 무한 루프를 초래할 수 있습니다.
그러나 특정 상황에서는 @JsonIgnore
가 문제 해결의 대안으로 사용될 수 있습니다. 예를 들어, API의 특정 버전에서 순환 참조를 피하기 위한 임시 방편으로 @JsonIgnore
를 사용해 해당 필드를 무시하여 직렬화 문제를 해결할 수 있습니다. 이는 특히 복잡한 엔티티 구조에서 데이터 노출과 관련된 특정 이슈를 빠르게 해결하고자 할 때 유용합니다.
하지만 이런 조치는 일반적으로 권장되지 않으며, 장기적인 관점에서 봤을 때 엔티티 대신 DTO(Data Transfer Object)를 사용하여 복잡한 API 데이터 표현을 관리하는 것이 더 효율적이고 안전한 방식입니다. DTO를 사용하면 API 스펙을 안정적으로 유지하면서도 데이터 모델과 API 응답을 분리하여 다양한 버전 관리가 용이해집니다.
다음의 링크에서 추가적인 설명을 확인하실 수 있습니다:
- @JsonIgnore 사용과 관련하여 질문드립니다.: 엔티티와 DTO 변환 시 @JsonIgnore의 사용과 그로 인한 영향에 대한 토론이 있습니다.
- 간단한 주문 조회 V1: 엔티티 직접 노출: 엔티티 노출과 관련된 구체적 문제 및 해결 방법을 다루고 있습니다.
이러한 내용을 참조하여 학습하신다면, 강의에서 다뤄진 @JsonIgnore
의 사용에 대한 전체적인 맥락을 이해하는데 도움이 될 것입니다. 처음에는 최악의 방법으로 설명되었더라도, 특정한 상황에서 문제를 해결하기 위한 도구로 사용할 수 있음을 이해하시면 됩니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
감사합니다!!