이 내용은 구체적인 응용 프로그램에 매우 구체적이라는 것을 알고 있지만, 나는 단지 일반적인 견해 또는 적어도이 문제에 대한 개인적인 경험이 무엇인지 궁금합니다.JPA 지연로드 성능 이점은 얼마나 중요합니까?
필자는 '열린 세션의 뷰'패턴에 대한 싫어함을 피하기 위해 모든 것을 열심히 가져 와서 서비스 레이어의 쿼리를 사용하여 큰 내용을 가져 오는 것에 대해 생각하고 있습니다.
누구든지 이것을 사용하고 후회 했습니까? 그리고 내가 알지 못하는 뷰 레이어에서 느슨한 로딩에 대한 우아한 해결책이 있습니까?
지연로드는 문제가되는 데이터를 전혀 사용하지 않을 경우에만 유용합니다 (예 : 고객 목록 만 표시하여 중첩 된 주문 집합은 무시함). 또는 아직 결정하지 않을 경우에만 유용합니다. 사용자는 문제의 데이터를보고 싶습니다 (예 : 메모리에 고객 목록이 있고 주문 목록에 대한 요청은 향후 조치에 따라 다릅니다).
모든 데이터를 한 번에 표시하려면 지연로드가 필요하지 않으며 추가 쿼리 비용이들 수 있습니다.
잘 설계된 스키마와 엔티티가 응용 프로그램의 다른 엔티티에 광범위하게 매핑되는 엔티티가있는 경우 기본적으로 지연로드가 필요합니다. 충분히 간단한 엔티티가 많은 추천 한 매핑
사람
추천 한 두 사람 (참조 자 및 참조되는)
하나: 여기에 매우 기본적인 예이다 , 권리? 음,이 두 관계에서 열심히로드하는 경우, 대부분의 상황에서 표시되지 않을 데이터에 대한 후속 쿼리가 계속 발생할 수 있습니다. 예를 들어
:
앱 그는 3 개 고객에 대해 참조로, 기록 "인물"및 3 개 추천 기록을 가지고이 인물을로드하고 싶어: PersonCPersonB, , 그리고 PersonD.
따라서이 관계에서 Eager를 가져 오는 경우 JPA는 이러한 3 인 레코드를로드합니다. 그리고 PersonC은 10 개의 고객을 추천했습니다. 왜냐하면 그는 당신의 판매가 무엇이든간에 무엇이든 사랑하기 때문입니다. 이제 JPA는 열 개의로드로 인해 다시 10 명의 고객을로드해야합니다.
어디로 가는지 확인할 수 있습니다. 이것이 게으른로드 된 관계였던 경우,이 여분의 데이터 세트가로드되는 유일한 시간은 직접 getReferrals() 호출을 수행 할 때입니다.
개인적으로 나는 이러한 가져 오기를 수행하는 추가 방법을 만들지 않아도됩니다. 코드에 대한 많은 추가 작업이 필요합니다. 이제 엔티티의 상태와 추가로드를 수행해야하는지 여부를 어떻게 든 관리해야합니다.
지연로드를 사용하는 경우 JPA를 사용하면이 작업을 쉽게 수행 할 수 있습니다. POJO와 JPA가 일반적으로 엔터티에서 수행하는 ...() 호출을 수행하면됩니다.
나는 이것이 성능상의 이점이 어디서 왔는지에 동의하지만, 나는 그들이 정말로 중요한지 알아 보는 데 관심이 있으며, 코드 우아함을 희생하는 가치가있다. 물론 모든 데이터가 한 번에 표시되는 경우는 거의 없지만 어쨌든 고객의 주문을 지연로드하고 싶지는 않을 것이며 수천 개가 될 수 있으며 페이지가 매겨져 사용자 지정 쿼리가 필요합니다. 예를 들어, 고객이 주소 개체를 가지고있는 경우, 열심히로드 할 정도로 작아 보이는 것처럼 여기에 게으른 필요도 없습니다. 내 의심이 맞습니까? 게으름 로딩은 문제가되지 않을까요? –
실제로 얼마나 많은 메모리가 불필요하게 소모되는지에 따라 달라집니다. 가능한 한 메모리 효율이 좋도록 응용 프로그램을 만들고 싶습니다. 프로파일 러는 새로운 통찰력을 줄 수 있습니다. – BalusC