JPA의 소개(section1)

JPA의 소개

📖 JPA를 사용하기 전에 어떻게 발전해왔고 왜 사용하는지를 알고 써야 하기에 정리해봅니다.

지금은 객체를 관계형 DB에 넣어서 관리를 한다.

하지만 실상은 테이블 마다 SQL문법을 적어야 했기 때문에 맵핑을 하는 것에 상당량 시간을 허비하게 되었다.

public class Memeber {
	privaet String memberId;
	privaet String name;
}

			INSERT INTO MEMBER(MEMBER_ID, NAME) VALUES
			SELECT MEMBER_ID, NAME FROM MEMBER M
			UPDATE MEMBER SET ... 

위와 같은 쿼리 식을 수행해야 하게 된다. 하지만 기획자가 연락처를 추가하게 
부탁을 하게 되는 경우 모든 쿼리를 다 수정하고 객체를 수정해야 하는 
비 효율적인 부분이 생기게 된다. 쿼리를 수정하는 과정에서 한 부분을
수정하지 않게 되면 코드에서 에러가 날 수 밖에 없게 된다.

📖 관계형DB vs 객체

관계형 DB

1. 관계형 DBPK, FK로 필요한 데이터를 찾을 수 있다.
2. 상속이 없다.

객체

1. 객체서로 참조를 할 수 있다.
2. 상속이 있다.

📖 관계형DB와 객체 조회의 차이점

🧐객체의 경우 INSERT시 ALBUM객체를 INSERT후 ITEM에도 INSERT해야 하게 된다. ALBUM을 조회 할 시에는 ITEM과 ALBUM을 JOIN한 후 조회 하는 번거로운 일을 하게 된다.

위와 같은 번거로운 일을 하지 않고 컬렉션의 관점에서 본다면? 아래의 코드처럼 아주 간단한 방식으로 조회를 할 수 있는 걸 볼 수 있다.

---

📖 관계형DB와 객체의 연관관계

1. 객체의 경우 참조로 이용해 찾아 갈 수 있지만 테이블의 경우 pk, fk의 값으로 join을 하여 참조 할 수 있다.
2.  객체의 경우 Team에서 Member의 값을 참조하는 부분이 없기에 Team.getMemeber()같이 참조를 할 수 없다.

1. 테이블의 경우 TEAM에서 TEAM_ID가 있기에 MEMBER로 갈 수 있으며 MEMBER의TEAM_ID(FK)를 역 참조를 할 수 있다.

그래서 우리가 할 일은 아래처럼 테이블형 연관관계의 데이터를 객체dml 연관관계로 하는 것이다. 하지만 이렇게 객체 지향적으로 설계를 할 경우 조회시에 또 문제가 생긴다.

😶‍🌫️조회시 생성되는 문제 마지막 member.setTeam(team)으로 개발자가 직접 연관관계를 셋팅하게 된다.

📖 객체 지향적으로 컬렉션에 값을 저장한다고 생각하게 한다면 쉽게 변한다. 아래처럼 객체만을 볼 때에는 밑처럼 쉽게 되지만 DB에 넣게 되는 순간 위의 복잡한 쿼리를 직접 수행해야 하는 것이다.

📖 객체간의 원하는 데이터를 찾을때도 문제가 생긴다 아래와 같은 그림에서 본다면 Member에서 Delivery객체를 참조 할 수 있어야 하지만 실상은 다르다.

처음 시작하는 SQL에서 이미 범위가 결정되기 때문에 처음에 MEMBER와 TEAM을 합한 후 데이터를 넣고 그 다음 getOrder을 했을 시에 값이 모두 채워져있다면 값이 가져와지지만 그렇지 않다면 null값을 가져오게 된다. 이럴 경우 엔티티의 신뢰 문제가 생긴다.

memberDAO의 값이 어떻게 짜여졌는지 확인을 실제로 하기 전에는 사용할 수 없다. 왜냐하면 레이어드 아키텍쳐 구간에서 신뢰의 문제가 발생하기 때문이다.(그 다음 계층에서 신뢰를 할 수 있어야 사용 가능하기 때문에)

아래와 같이 SQL적 문법에서 본다면 member1, member2는 각각 new Member를 생성하기 때문에 결과적으로 값이 달라진다.

그렇지만 컬렉션의 관점에서 본다면 아래의 값은 같게 된다. 그렇기 때문에 객체를 컬렉션에 저장하듯이 DB에 저장하는 법을 고민하게 된다.

📖 그렇기 때문에 나온 것이 바로 신이 내린 선물 JPA이다.

 

 📖 JPA란 JAVA ORM의 표준이다. 그 말이란 즉 위의 포스팅에서 말했던 객체적으로 만든 데이터를 DB에 밀어넣을때 ORM 프레임워크인 JPA로 맵핑을 해주겠단 소리이다. 그렇기에 JPA에 대해서 알아보자

JPA의 동작 원리

예를 들어 JPA에게 MemberDAO에 값을 넣고자 member객체를 넘기게 된다면 JPA가 자동적으로 insert쿼리를 생성하고 DB에 보내고 값을 받게 된다. JPA란 즉 원하는 동작에 맞는 쿼리를 자동적으로 생성해주는 것이다.

---

그렇다면 JPA를 사용해야 하는 이유는 뭘까?

생산성 : 이미 코드가 다 만들어져있기 때문에 아래처럼 불러쓰면 된다

• 특히 수정 부분에서 set만을 사용하는 것만으로 수정이 된다. 컬렉션에서 사용한다고 생각하면 이해하기 편한데 JAVA 컬렉션에서 값을 찾은 후 수정시에 다시 값을 넣지 않기 때문에 이런 부분에서 편하다고 할 수 있다.

유지 보수 : 쿼리 단을 생각할 필요가 없다!

• 기본 적으로 연락처를 추가 시에 아래의 쿼리문을 수정해야 했다면 JPA를 사용하게 되면 JPA에서 자체적으로 쿼리문을 만들어 수행하기 때문에 SQL의 쿼리문을 수정 할 필요가 없게 된다.!

 

패러다임의 불일치 해결!

• 기본 적으로 아래의 데이터 관계를 구상하고 직접 쿼리문을 짜야 했다면 이제는 JPA를 사용하게 편리하게 된다.

• JPA를 이용해서 아래의 member 객체를 들고 온다면 JPA의 지연 로딩(구문이 실행되는 순간 작동하는 구문 예를 들어 member.getTeam이 시작되는 시점에 member객체에 쿼리문을 사용하여 데이터를 채워준다.)을 이용하여 아래의 구문을 신뢰 할 수 있다.

성능 최적화

• 동일 Transactional안에서는 동일성을 보장한다.

• JPA는 쿼리들을 받은 후 메모리에 쌓아둔 후 commit시점에 같은 쿼리들을 옵션을 하나 킨 것만으로 한 번에 보낸다.

• 지연 로딩 : member객체를 꺼낸 후 getTeam으로 들고온 team을 건들게 될 때 실제 DB에 쿼리 값을 보내 team의 데이터를 들고 오게 된다. 쉽게 말하면 아래의 그림에서 Team team = member.getTeam();시점에 team의 값을 조회하는 쿼리를 보내는 것이 아니라 String teamName = team.getName();시점에 team을 건드는 쿼리를 날리는 것이다.
• 즉시 로딩 : 실제로 사용시 대부분의 경우 member를 사용시 team을 들고 와야 한다면 JPA의 옵션을 사용하여 즉시 로딩을 이용해 member를 들고 올 때 team을 들고 오게 한다. 그리고 사용 시 이미 로딩된 데이터를 들고 온다.

출처 : https://inf.run/spjG