You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
현재 ListEntity와 Label, 그리고 Item과 양방향 매핑이다. 다른 의미로 순환 참조가 발생하고 있다.
이로 인해 객체 생성에 어려움이 있다. 또한 순환 참조는 그 자체로 많은 문제를 야기할 수 있다. (Stack Overflow)
따라서 단방향 매핑으로 수정할 필요가 있다.
다른 관점에서 DB와 JPA를 모두 떼고 순수 객체의 관점으로 봤을 때, ListEntity가 Item과 Label을 의존할 필요가 없다.
Item과 Label은 추가, 변경, 삭제가 매우 잦은 객체이므로 이들을 의존하는 것은 ListEntity에도 많은 변경 포인트를 낳는다.
현재 ListEntity를 조회함으로써 Item과 Label을 쉽게 조회할 수 있다는 장점이 있지만, 위에 언급한 단점들에 비해 너무 강력하지 못한 장점이라고 생각한다.
조회 성능 관점에서도 LAZY 로딩을 하더라도, 결국 DTO에 값을 담을 때에는 DB에 JOIN을 통해 조회하게 된다. 결과적으로 똑같다.
쓰기 성능 관점에서는 ListEntity는 신경 쓸 필요없이, 단순하게 Label과 Item 엔티티만 추가, 삭제, 변경하면 되므로 더 좋을 것으로 예상된다.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
현재 ListEntity와 Label, 그리고 Item과 양방향 매핑이다. 다른 의미로 순환 참조가 발생하고 있다.
이로 인해 객체 생성에 어려움이 있다. 또한 순환 참조는 그 자체로 많은 문제를 야기할 수 있다. (Stack Overflow)
따라서 단방향 매핑으로 수정할 필요가 있다.
다른 관점에서 DB와 JPA를 모두 떼고 순수 객체의 관점으로 봤을 때, ListEntity가 Item과 Label을 의존할 필요가 없다.
Item과 Label은 추가, 변경, 삭제가 매우 잦은 객체이므로 이들을 의존하는 것은 ListEntity에도 많은 변경 포인트를 낳는다.
현재 ListEntity를 조회함으로써 Item과 Label을 쉽게 조회할 수 있다는 장점이 있지만, 위에 언급한 단점들에 비해 너무 강력하지 못한 장점이라고 생각한다.
조회 성능 관점에서도 LAZY 로딩을 하더라도, 결국 DTO에 값을 담을 때에는 DB에 JOIN을 통해 조회하게 된다. 결과적으로 똑같다.
쓰기 성능 관점에서는 ListEntity는 신경 쓸 필요없이, 단순하게 Label과 Item 엔티티만 추가, 삭제, 변경하면 되므로 더 좋을 것으로 예상된다.
Reference
Beta Was this translation helpful? Give feedback.
All reactions