JPA 를 얘기할때 패러다임의 불 일치를 해결했다 라는 내용이 잘 이해못하겠습니다.

Question

JPA 를 설명할때 영한쌤도 그렇고 많은 글 에서 패러다임의 불일치를 해결했다라는 부분이 보입니다.일단 제가 이해한건 다음과 같습니다.자바 와 같은 다양한 언어는 오늘날에 객체 지향 을 추구 하고 있습니다. RDB 의 경우에는 관계형 을 추구합니다.자바를 예를 들어 다음과 같은 형태의 데이터 상속 구조를 가질수 있습니다.class Order { Member member; Address address; }하지만 DB 에서는 상속이라는 개념은 없고 단지 관계를 나타내기 위해 외래키(PK,FK) 를 사용하여 테이블간 의 관계를 나타냅니다.DB 에서는 위와 같이 관계가 있는 데이터를 조회하기 위해 INNER JOIN 과 같은 쿼리를 사용하여 조회를 해야한다.이정도 까지는 이해를 했습니다. 이후 하이버네이트 에서는 이러한 문제를 해결하기 위해 자동으로 매핑하는 솔루션을 만들었다. 라고 작성이 되어 있긴 합니다.https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html다만 이 패러다임의 불 일치가 어떠한 문제가 있는지 잘 모르겠습니다.가령 mybatis 에서는 다음과 같은 join 된 데이터를 가져올때.다음과 같은 형태로 결과를 담기 위한 VO 객체를 생성하여 담아 사용합니다. 물론 불편하다고 하면 불편할수 있겠으나..JPA 에서 또한 JPQL 이 결국 JOIN 쿼리를 을 생성하여 결과를 담는 것에는 큰 차이가 없는걸로 보입니다.public class MemberOrderVO { private Long memberId; private String memberName; private Long orderId; private String itemName; } SELECT m.id AS memberId, m.name AS memberName, o.id AS orderId, o.item_name AS itemName FROM member m JOIN orders o ON m.id = o.member_id WHERE m.id = #{memberId}JPA 특성중 특정 DB 에 종속적 이지 않는다 라는 내용은 다른 부분을 해결한 거 같고.. JPA 고수 형님들 패러다임의 불일치를 해결했다 라는 것이 도대체 무엇입니까.?

kyuho · Accepted Answer

가령 mybatis 에서는 다음과 같은 join 된 데이터를 가져올때.다음과 같은 형태로 결과를 담기 위한 VO 객체를 생성하여 담아 사용합니다. 물론 불편하다고 하면 불편할수 있겠으나..JPA 에서 또한 JPQL 이 결국 JOIN 쿼리를 을 생성하여 결과를 담는 것에는 큰 차이가 없는걸로 보입니다.MyBatis 방식과 JPA 방식을 비교하면 명확해져요.MyBatisJOIN 결과를 담을 VO(DTO) 생성은 많이 선택하는 방법이에요. 개발자는 항상 SQL 결과를 중심으로 사고해야 해요.JPADTO로 결과를 받는 것은 성능 최적화를 위한 선택 사항이에요. JPA의 기본이자 핵심은 order.getMember()처럼 엔티티 객체의 연관관계를 그대로 탐색하는 것이고요.객체 그래프 탐색으로 보면MyBatisOrder 를 조회 후, 관련된 Member 를 얻으려면 Member 조회 쿼리를 또 실행해야 해요. 객체 간의 연관관계가 코드상에서 자연스럽게 이어지지 않죠. order.getMember() 가 의미 없어지는거죠.JPAOrder 조회 후, order.getMember() 를 호출하면 JPA가 알아서 필요한 시점에 Member를 조회하는 쿼리를 실행해줘요. 모든 객체가 메모리에 있는 것처럼 객체 그래프 탐색이 가능해요.JPA가 '패러다임 불일치'를 해결했다는 것은, SQL이나 DB 테이블 구조에 얽매이지 않고, 오직 자바 객체지향 관점에서만 프로그래밍할 수 있게 해줬다는 의미에요.

감독님테스트가하고싶어요 · Answer

VO로 변환하여 조회결과를 받을 경우 패러다임의 불일치 해결을 느끼기 힘듭니다.엔티티 중심으로 생각해보세요.

장독깨기 · Answer

https://hibernate.org/orm/what-is-an-orm/여기 한 번 읽어보세요, 불일치로 생기는 문제들이 있는것 같습니다.아, 그리고, 저 내용에 전 동의하지 않습니다.그게 왜 문제인가? 그게 문제라면 시스템을 구축하는데 무슨 영향력이 있는가?없는 문제를 문제라고 우기는 것은 아닌가? ㅎ전 대략 이렇게 생각합니다. : )

개발잡부 · Answer

DB에서 select한 값을 바로 객체에 담을 수 없고, 따로 이름이나 값을 조작을 해서 객체에 넣는게 아니라DB의 이름,값이 class와 1:1 매핑이 되어서 그렇습니다.

전뚱이인데요 · Answer

강의 보셨으면 패러다임 불일치에 대해서 설명이 잘 나와있을텐데.. 그런데도 이해가 안되신거에요?객체는 서로 참조하면서 관계를 맺고관계형 디비는 pk, fk 관계를 표현하는데 모델링 중심도 객체는 행동, 즉 메서드 중심적으로 설계하고관계형 디비는 데이터 중심이잖아요JPA는 이 둘의 차이점을 Entity 설계로 패러다임의 차이점을 해결한것인데데이터베이스에서 crud를 객체지향스럽게 할 수 있잖아요 그게 패러다임의 차이점을 해결한것이죠예를 들어 Entity 에서 remove 하여 데이터를 삭제 하면 실제 디비에서도 반영되고.. Team Entity 에서 Member 조회 하면 join 해서 데이터 가 조회 되는것들이 패러다임 불일치를 해결한거잖아요 아직도 이해가 어렵다고 하시면 객체지향에 대해서 더 공부하시면 이해하게 되실거 같아요

yeori · Answer

아래의 dto는 관계형 디비에서 두 테이블 users와 orders의 관계를 뭉개서 표현한 겁니다.public class MemberOrderVO { private Long memberId; private String memberName; private Long orderId; private String itemName; }애플리케이션 요구사항에 맞춰서 User와 Order의 구조를 합쳐버린 것이고, 저런 것들을 지루하게 만들고 싶지 않다는 요구에서 하이버네이트같은게 나오게 됩니다.디비에서는 엔티티간의 관계를 외래키로 나타냅니다. 아래처럼...users(seq:PK, ....) orders(... member_id:FK)orders.member_id 가 외래키라는 것에서 이미 양방향 조회가 가능해 집니다.특정 사용자의 주문 내역을 가져오기특정 주문의 주문자를 가져오기하지만 객체 세상에서는 양방향 관계를 나타내기 위해서 양쪽 모두에 참조를 정의해야 합니다.class User { Set<Order> orders; // 특정 사용자의 주문 내역 }class Order { User owner; // 주문자 }그 문서에서 말하는 패러다임 불일치의 대표적인 현상입니다.왜 이런 현상이 생기냐면...관계형 디비는 집합 개념에서 발명됐습니다. 얘네들은 엔티티를 집합 중심으로 표시합니다. 그래서 엔티티간의 구조를 표현하는게 빡쎕니다.(트리구조 생각하면 좋음. 전용 쿼리가 따로 있을 정도임)반면 객체세상에서는 엔티티간의 구조 를 잘 표현하기 위해서 발명됐습니다. 그래서 관계에 방향성이 있습니다.위에서 보이듯이 사용자의 주문내역이라는 관계의 방향이 따로, 반대로 주문의 입장에서는 주문을 낸 사람을 가리키는 방향이 따로입니다. 하지만 관계형디비에서는 외래키 필드 하나가 양쪽 방향을 다 나타냅니다.관계형디비가 1970년도 중반에 발명됐고, 객체지향도 얼추 비슷한 시기에 개념화됐습니다.양쪽이 각자 자기 문제를 해결하느라 따로 발전하다가 1990년도에 와서야 애플리케이션이 데이터베이스를 밀접하게 사용하면서 관계를 표현하는 양쪽의 방법이 완전히 다르다는 걸 알게 됐습니다.위에 예로 든 DTO들을 발라대면서 뭔가 계속 비슷한 짓을 하고 있다는 것을 느끼는 사람들이 많았고, 양쪽 진영의 불일치를 근본적으로 해결하려고 온갖 삽질을 한 끝에 하이버네이트같은 게 나옴.

JPA 를 얘기할때 패러다임의 불 일치를 해결했다 라는 내용이 잘 이해못하겠습니다.

6개의 답변

Q&A 목록