JPA 필요성 - SQL 중심적인 개발의 문제점

백마금편·2022년 2월 1일
0

JPA

목록 보기
2/2

🎯 객체 vs 관계형

객체 지향적 언어

  • JAVA, Scala 등 객체 지향적인 언어

관계형 데이터베이스

  • Oracle, MySQL 등 관계형 데이터베이스

객체를 관계형 데이터베이스에 저장

  • 새로운 기능의 CRUD(Insert, Update, Select, Delete)를 구현하기 위해 수많은 자바 객체 ↔ SQL 매핑 과정을 거쳐야 한다.
  • 객체를 보관 하는 방법 RDB, NoSQL, File 등 여러 방법이 존재하지만 현실적인 대안은 RDB이다.
  • 개발자는 SQL 매퍼인가?? SQL에 의존적인 개발을 피하기 어렵다.

👨‍💻 객체와 관계형 데이터베이스의 차이

객체 vs 관계형 데이터베이스

❗ 상속

  • Album Table에 객체 저장
    Insert Into Album...
    Insert Into Item ...
    Item, Album Table 각각 Insert 로직을 실행해야한다(뭔가 번거롭다... 🤔)

  • 조회
    각각 테이블 Join 후 Select
    각각 객체 생성
    각각 ...
    각..

    관계형 데이터베이스가 아니라 자바 컬렉션에 저장하고 조회한다면??

    list.add(album); // 저장
     Album album = list.get(albumId);
     Item item = list.get(albumId); // 부모 타입으로 조회 후 다형성 활용

❗ 연관관계

객체 테이블 연관관계

  • 객체
    참조를 사용: member.getTeam()
    Member객체에서 Team 객체 참조 가능
    Team 객체에서 Member 객체 참조 불가능
  • 테이블
    외래 키를 사용: JOIN ON M.TEAM_ID = T.TEAM_ID
    Member Table과 Team Table은 외래키를 통해 참조 가능
객체를 테이블에 맞춰서 모델링
class Member {
    String id; // MEMBER_ID 컬럼 사용
    Long teamId; // Team_id KF 컬럼사용
    String username; // USERNAME 컬럼 사용
}

class Team {
	Long TEAM_ID; // TEAM_ID PK 컬럼 사용
	String name; // NAME 컬럼 사용
}

위처럼 모델링한 객체로 MEMBER TABLE에 Insert 쿼리문
INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES...
TEAM_ID는 외래키는 참조 객체인거 같고 전혀 객체지향적이지 않아 보인다
아래 처럼 조금 더 객체 지향적으로 모델링이 가능하다.

class Member {
    String id; // MEMBER_ID 컬럼 사용
    Team team;
    String username; // USERNAME 컬럼 사용
    
    Team getTeam() {
    	return team;
    }
}

class Team {
	Long TEAM_ID; // TEAM_ID PK 컬럼 사용
	String name; // NAME 컬럼 사용
}

위처럼 모델링 하면
INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES...
TEAM_ID ➡️ member.getTeam().getId()로 구할 수 있다.
다소 복잡하지만 객체 지향적인거 같다.
하지만 조회시에는?

SELECT M.*
       T.*
  FROM MEMBER M
      ,TEAM T
  JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID

해당 쿼리 결과를 객체에 넣기 위해서는
SQL문 실행 ➡️ MEMBER 객체 생성 ➡️ MEMBER 객체에 데이터 입력 ➡️ TEAM 객체 생성 ➡️ TEAM 객체에 데이터 입력 ➡️ MEMBER 객체와 TEAM객체 관계 설정
자바 컬렉션에서 관리는 쉽지만 데이터베이스에 넣고 빼는 순간 복잡해진다.

결국 MemeberWithTeam 객체 처럼 Super 객체럴 만들어 다 때려 넣는다.

❗객체 그래프 탐색

  • 객체는 자유롭게 탐색할 수 있어야 한다
class MemberService {
	public void precess() {
    	Member member = memeberDAO.FIND(memberID);
		member.getTeam(); // null ??
		member.getOrder().getDelivery(); // null ??
	}
}

memberDAO.FIND 함수를 재사용할때
member.getTeam()
member.getOrder().getDelivery()
해당 객체 참조시 신뢰할수가 없다 ➡️ 엔터티 신뢰 문제

  • 모든 객체를 미리 로딩할 수 없다.
  • 실행되는 SQL에 따라서 탐색 범위가 달라진다.
  • 계층형 아키텍처 진정한 의미의 계층 분할이 어렵다.
  • 물리적으로는 분리되어 있지만 논리적으로는 강결합 되어 있다.

🏅 결론

  • 객체 지향적으로 모델링 할수록 매핑 작업만 늘어난다.

    객체를 자바 컬렉션에 저장하듯이 데이터베이스에 저장할수없을까? JPA


📖 참고 자료

profile
뭐 어떻게 잘 되겠지

0개의 댓글