JPA 개요
n JAVA는 표준 스펙을 정하고 그 구현을 DB벤더에게 맡기는 JDBC를 통해 최초 영속성 관리를 지원했는데 JDBC는 SQL중심의 트랜잭션 스크립트 방식의 개발을 지원했으며 엔터프라이즈 환경에서 잘 적용되었다.
n JDBC이후 데이터소스를 이용한 커넥션관리, JNDI를 통한 리소스 관리 등으로 변환 발전.
n 1990년대 후반에 등장한 EJB 기술은 JDBC의 트랜잭션 스크립트 방식을 벗어나 자바 객체의 특징을 유지한 채로 퍼시스턴스 기술을 적용할 수 있는 엔티티빈을 소개했다. 하지만 이러한 기술은 JDBC 방식에 비해 성능 오버헤드가 많았으며 시대적 상황상 객체를 정확히 DB에 매핑하지 못하는 어려움도 있었다.
n 이러한 엔티티빈의 대안 기술로 오라클의 TopLink와 같은 퍼시스턴스 프레임워크, 오픈소스로 등장한 POJO 기반의 하이버네이트, 엔터프라이즈 환경에도 사용 가능한 자바 모델 기반의 퍼시스턴스 기술인 JDO(Java Data Object)등이 있다.
n EJB3.0의 등장! EJB의 명성을 찾기 위한 노력의 결과로 EJB 설계 팀은 EJB3.0을 EJB2.X 기술의 상당 부분을 포기하는 한이 있더라도 새로운 모델로 접근하기로 결정하고 새로운 전문가그룹(expert group)의 멤버를 영입했다.
n 초기 EJB 스펙을 설계하는 주도적인 역할에 참여한 사람이 바로 하이버네이트의 창시자이자 그 즈음에 JBoss팀에 차세대 JBoss 서버의 JDO 개발의 책임자로 영입된 개빈 킹(Gavin King)이다. 개빈 킹은 하이버네이트를 통한 POJO 기반의 퍼시스턴스 프레임워크에 대한 기술적인 확신과 경험을 담아 EJB3.0의 엔티티빈 스펙을 완전히 새롭게 구성해 나가기 시작했다.
n EJB3.0 스펙 작업을 하고 있던 전문가 그룹은 엔티티빈, CMP파트를 독립적인 스펙으로 분리 했는데 이는 J2EE WAS를 구매할 때 CMP 엔진은 다른 벤더 제품을 쓸 수도 있다는 뜻이기 때문이다. 즉 따라서 특정 벤더에모든 것을 종속 당할 필요가 없어진 것인데 WebLogic 서버를 사용하면서 엔티티빈 엔진은 하이버네이트 기반의 CMP 엔진을 써도 된다는 것을 뜻하는 것이다.
n 결과적으로 EJB3.0 스펙은 두 가지로 구분이 되었다. 하나는 SessionBean과 MessageDriven Bean이고, 또하나는 EJB3 Java Persistence API(JPA)이다.
n JPA는 스펙이 분리된 후 이름이 엔티티빈에서 JPA로 변경되었고 EJB 엔티티빈의 경량화와 개선에 머무른 것이 아니라 새로운 이름으로 자바의 모든 기술과 환경에서 사용할 수 있는 독립적인 POJO 기반의 퍼시스턴스 프레임워크로 새롭게 시작된 기술로 발전했다.
n JPA(Java Persistence API)는 관계형 데이터베이스(RDB)에 접근하기 위한 표준 ORM 기술을 제공하며, 기존 EJB에서 제공되던 엔터티 빈(Entity Bean)을 대체하는 기술이다.
n JSR-220에서 EJB의 ORM인 EntityBean(3.0)을 JPA로 통합하였고, 자바에서 영속성 관리를 위한 표준 API 이다.
n JPA는 Hibernate, OpenJPA, EclipseLink, TopLink Essentials과 같은 구현체가 있는데 이들의 표준 인터페이스가 바로JPA이다.
n EJB의 엔티티빈 과는 다르게 일반 POJO빈을 이용한 프로그래밍 모델을 제공하며 EJB에 국한되지 않도록 만들었기에 JavaSE, JavaEE 모두에서 사용 가능한 표준 API 이다.
n 자바 객체와 RDB의 테이블을 Mapping하는 방법을 제공하며 어노테이션 및 XML 형태 모두 사용가능하고 자바객체간의 상속관계도 지원한다.
n 잘 이해하고 사용하지 않으면 데이터 손실이 발생할 수 있으며 성능 문제 등이 야기 될 수 있으므로 정확히 이해하고 사용하는 것이 좋다.
n 스프링 프레임워크에서는 Spring Data JPA를 제공하여 JPA기반 Repository를 구현할 수 있도록 지원하고 있다.
n 장점
ü SQL 쿼리구문을 직접 작성할 필요가 없다.
ü 데이터를 객체지향적으로 관리 하므로 프로그래머는 비즈니스 로직에 좀 더 집중 할 수 있고 테이블의 구조가 변경 되는 경우 기존 SQL을 사용하는 방식 보다 변경이 용이하다.
ü DB에 의존적이지 않는 코드 작성이 가능하다. (DB가 바뀌더라도 변경해야 하는 코드가 거의 없으므로 다양한DB에 대해 서비스하는 경우라면 적합하다.)
n 단점
ü 완벽하게 복잡한 쿼리구문을 작성 못할 수도 있다. 물론 이를 위해 Native SQL도 사용가능 하지만 이는 하나의 DB에 의존적인 코드가 될 수 있다.
ü DB모델링을 객체지향적으로 해야 한다. 테이블에서 데이터를 조회하는 것이 아닌 객체에서 조회한다고 생각하고 모델링 해야 한다. 객체지향 및 데이터베이스 양쪽 모두 잘 알고 있어야 한다.
ü 데이터베이스 테이블에 해당하는 도메인 객체 설계와 관계 설정을 이해해야 되고 객체지향 쿼리언어인 JPQL(Java Persistence Query Language) 또는 criteria 쿼리 등도 이해해야 한다.
댓글 없음:
댓글 쓰기