Why JPA?

Persistence Mechanisms

Supports:

Serialization

JDBC

ORM

ODB

EJB 2

JDO

JPA

Java Objects

Yes

Advanced OO Concepts

Yes

Transactional Integrity

Yes

Concurrency

Yes

Large Data Sets

Yes

Existing Schema

Yes

Relational and Non-Relational Stores

Yes

Queries

Yes

Strict Standards / Portability

Yes

Simplicity

Yes

Serialization은 객체 그래프를 네트워크를 통해 전송하거나 파일에 저장할 수 있는 일련의 바이트로 변환하기 위한 Java의 기본 메커니즘입니다. 직렬화는 사용하기 매우 쉽지만 매우 제한적입니다. 전체 객체 그래프를 한 번에 저장하고 검색해야 하므로 많은 양의 데이터를 처리하는 데 적합하지 않습니다. 정보를 업데이트하는 동안 오류가 발생하면 객체에 적용된 변경 사항을 취소할 수 없으므로 엄격한 데이터 무결성이 요구되는 응용 프로그램에 적합하지 않습니다. 여러 스레드 또는 프로그램은 서로 충돌하지 않고 동일한 직렬화된 데이터를 동시에 읽고 쓸 수 없습니다. 쿼리 기능을 제공하지 않습니다. 이러한 모든 요인으로 인해 직렬화는 가장 사소한 지속성 요구 사항을 제외하고는 모두 쓸모가 없습니다.
많은 개발자가 JDBC(Java Database Connectivity) API를 사용하여 관계형 데이터베이스에서 영구 데이터를 조작합니다. JDBC는 대량의 데이터를 처리할 수 있고, 데이터 무결성을 보장하는 메커니즘이 있으며, 정보에 대한 동시 액세스를 지원하고, SQL에 정교한 쿼리 언어가 있는 등 직렬화의 단점을 대부분 극복합니다. JDBC에서 사용하는 관계형 패러다임은 객체를 저장하도록 설계되지 않았으므로 영구 데이터를 처리하는 코드 부분에 대한 객체 지향 프로그래밍을 포기하거나 상속과 같은 객체 지향 개념을 관계형 데이터베이스에 직접 매핑하는 방법을 찾는 것입니다.
객체와 관계형 데이터베이스 테이블 간의 매핑을 수행할 수 있는 툭스 소프트웨어 제품이 많이 있습니다. 이러한 ORM(개체 관계형 매핑) 프레임워크를 사용하면 객체 모델에 집중할 수 있으며 객체 지향 패러다임과 관계형 패러다임 간의 불일치에 대해 걱정할 필요가 없습니다. 안타깝게도 이러한 각 제품에는 고유한 API 집합이 있습니다.우리의 코드는 단일 공급업체의 특수 인터페이스에 연결됩니다. 공급업체가 가격을 인상하거나 눈에 띄는 버그를 수정하지 못하거나 기능이 뒤처지는 경우 모든 지속성 코드를 다시 작성하지 않고는 다른 제품으로 전환할 수 없습니다. 이를 벤더 락인(Lock-in)이라고 합니다.
객체를 관계형 데이터베이스에 매핑하는 대신 일부 소프트웨어 회사에서는 객체를 저장하도록 특별히 설계된 데이터베이스 형식을 개발했습니다. 이러한 객체 데이터베이스(ODB)는 종종 객체-관계형 매핑 소프트웨어보다 훨씬 사용하기 쉽습니다. 객체 데이터베이스 관리 그룹(ODMG)은 객체 데이터베이스에 액세스하기 위한 표준 API를 만들기 위해 구성되었습니다. 그러나 ODMG의 권장 사항을 준수하는 객체 데이터베이스 공급업체는 거의 없습니다. 따라서 공급업체 의존은 객체 데이터베이스에도 문제를 일으킵니다. 따 랏서 은기업들이 검증된 관계형 시스템에서 상대적으로 잘 알려지지 않은 객체 데이터베이스 기술로 전환하는 것을 주저하고 있습니다. 객체 데이터베이스 시스템에 사용할 수 있는 데이터 분석 도구가 적고 오래된 관계형 데이터베이스에 이미 방대한 양의 데이터가 저장되어 있습니다. 이러한 모든 이유와 기타 이유으로 인해 객체 데이터베이스는 기대한 만큼 인기를 얻지 못했습니다.
Java 플랫폼의 Enterprise Edition은 엔터티 EJBs(Enterprise Java Beans)를 도입했습니다. EJB 2.x 엔터티는 데이터 저장소의 영구 정보를 나타내는 구성 요소입니다. 객체 관계형 매핑 솔루션과 마찬가지로 EJB 2.x 엔터티는 영구 데이터의 객체 지향 view를 제공합니다. 그러나 객체 관계형 소프트웨어와 달리 EJB 2.x 엔터티는 관계형 데이터베이스로 제한되지 않습니다. 이들이 나타내는 영구 정보는 EIS(Enterprise Information System) 또는 기타 저장 장치에서 가져올 수 있습니다. 또한 EJB 2.x 엔터티는 엄격한 표준을 사용하므로 공급업체 간에 이식할 수 있습니다. 불행하게도 EJB 2.x 표준은 표현할 수 있는 객체 지향 개념에 다소 제한이 있습니다. 상속, 다형성 및 복잡한 관계와 같은 고급 기능이 없습니다. 또한 EBJ 2.x 엔터티는 코딩하기 어려우며 실행하려면 무겁고 종종 값비싼 애플리케이션 서버가 필요합니다
JDO 사양은 JPA와 놀랍도록 유사한 API를 사용합니다. 그러나 JDO는 비관계형 데이터베이스를 지원하며 일부에서는 이 기능이 사양을 희석시킨다고 주장합니다
JPA는 위에 나열된 각 지속성 메커니즘의 최상의 기능을 결합합니다. JPA에서 엔터티를 생성하는 것은 직렬화 가능한 클래스를 생성하는 것만큼 간단합니다. JPA는 JDBC의 대용량 데이터 세트, 데이터 일관성, 동시 사용 및 쿼리 기능을 지원합니다. 객체 관계형 소프트웨어 및 객체 데이터베이스와 마찬가지로 JPA는 상속과 같은 고급 객체 지향 개념의 사용을 허용합니다. JPA는 JDBC의 대용량 데이터 세트, 데이터 일관성, 동시 사용 및 쿼리 기능을 지원합니다. 객체 관계형 소프트웨어 및 객체 데이터베이스와 마찬가지로 JPA에서는 상속과 같은 고급 객체 지향 개념을 사용할 수 있습니다. JPA는 JDO 및 EJB 2.x 엔터티와 같은 엄격한 사양에 의존하여 벤더 종속을 방지합니다. JPA는 관계형 데이터베이스에 중점을 둡니다. 그리고 JDO와 마찬가지로 JPA는 사용하기가 매우 쉽습니다.

Reference

Last updated 1 year ago

Was this helpful?

Persistence Mechanisms

Supports:

Serialization

JDBC

ORM

ODB

EJB 2

JDO

JPA

Java Objects

Yes

Advanced OO Concepts

Yes

Transactional Integrity

Yes

Concurrency

Yes

Large Data Sets

Yes

Existing Schema

Yes

Relational and Non-Relational Stores

Yes

Queries

Yes

Strict Standards / Portability

Yes

Simplicity

Yes

Serialization은 객체 그래프를 네트워크를 통해 전송하거나 파일에 저장할 수 있는 일련의 바이트로 변환하기 위한 Java의 기본 메커니즘입니다. 직렬화는 사용하기 매우 쉽지만 매우 제한적입니다. 전체 객체 그래프를 한 번에 저장하고 검색해야 하므로 많은 양의 데이터를 처리하는 데 적합하지 않습니다. 정보를 업데이트하는 동안 오류가 발생하면 객체에 적용된 변경 사항을 취소할 수 없으므로 엄격한 데이터 무결성이 요구되는 응용 프로그램에 적합하지 않습니다. 여러 스레드 또는 프로그램은 서로 충돌하지 않고 동일한 직렬화된 데이터를 동시에 읽고 쓸 수 없습니다. 쿼리 기능을 제공하지 않습니다. 이러한 모든 요인으로 인해 직렬화는 가장 사소한 지속성 요구 사항을 제외하고는 모두 쓸모가 없습니다.

많은 개발자가 JDBC(Java Database Connectivity) API를 사용하여 관계형 데이터베이스에서 영구 데이터를 조작합니다. JDBC는 대량의 데이터를 처리할 수 있고, 데이터 무결성을 보장하는 메커니즘이 있으며, 정보에 대한 동시 액세스를 지원하고, SQL에 정교한 쿼리 언어가 있는 등 직렬화의 단점을 대부분 극복합니다. JDBC에서 사용하는 관계형 패러다임은 객체를 저장하도록 설계되지 않았으므로 영구 데이터를 처리하는 코드 부분에 대한 객체 지향 프로그래밍을 포기하거나 상속과 같은 객체 지향 개념을 관계형 데이터베이스에 직접 매핑하는 방법을 찾는 것입니다.

객체와 관계형 데이터베이스 테이블 간의 매핑을 수행할 수 있는 툭스 소프트웨어 제품이 많이 있습니다. 이러한 ORM(개체 관계형 매핑) 프레임워크를 사용하면 객체 모델에 집중할 수 있으며 객체 지향 패러다임과 관계형 패러다임 간의 불일치에 대해 걱정할 필요가 없습니다. 안타깝게도 이러한 각 제품에는 고유한 API 집합이 있습니다.우리의 코드는 단일 공급업체의 특수 인터페이스에 연결됩니다. 공급업체가 가격을 인상하거나 눈에 띄는 버그를 수정하지 못하거나 기능이 뒤처지는 경우 모든 지속성 코드를 다시 작성하지 않고는 다른 제품으로 전환할 수 없습니다. 이를 벤더 락인(Lock-in)이라고 합니다.

객체를 관계형 데이터베이스에 매핑하는 대신 일부 소프트웨어 회사에서는 객체를 저장하도록 특별히 설계된 데이터베이스 형식을 개발했습니다. 이러한 객체 데이터베이스(ODB)는 종종 객체-관계형 매핑 소프트웨어보다 훨씬 사용하기 쉽습니다. 객체 데이터베이스 관리 그룹(ODMG)은 객체 데이터베이스에 액세스하기 위한 표준 API를 만들기 위해 구성되었습니다. 그러나 ODMG의 권장 사항을 준수하는 객체 데이터베이스 공급업체는 거의 없습니다. 따라서 공급업체 의존은 객체 데이터베이스에도 문제를 일으킵니다. 따 랏서 은기업들이 검증된 관계형 시스템에서 상대적으로 잘 알려지지 않은 객체 데이터베이스 기술로 전환하는 것을 주저하고 있습니다. 객체 데이터베이스 시스템에 사용할 수 있는 데이터 분석 도구가 적고 오래된 관계형 데이터베이스에 이미 방대한 양의 데이터가 저장되어 있습니다. 이러한 모든 이유와 기타 이유으로 인해 객체 데이터베이스는 기대한 만큼 인기를 얻지 못했습니다.

Java 플랫폼의 Enterprise Edition은 엔터티 EJBs(Enterprise Java Beans)를 도입했습니다. EJB 2.x 엔터티는 데이터 저장소의 영구 정보를 나타내는 구성 요소입니다. 객체 관계형 매핑 솔루션과 마찬가지로 EJB 2.x 엔터티는 영구 데이터의 객체 지향 view를 제공합니다. 그러나 객체 관계형 소프트웨어와 달리 EJB 2.x 엔터티는 관계형 데이터베이스로 제한되지 않습니다. 이들이 나타내는 영구 정보는 EIS(Enterprise Information System) 또는 기타 저장 장치에서 가져올 수 있습니다. 또한 EJB 2.x 엔터티는 엄격한 표준을 사용하므로 공급업체 간에 이식할 수 있습니다. 불행하게도 EJB 2.x 표준은 표현할 수 있는 객체 지향 개념에 다소 제한이 있습니다. 상속, 다형성 및 복잡한 관계와 같은 고급 기능이 없습니다. 또한 EBJ 2.x 엔터티는 코딩하기 어려우며 실행하려면 무겁고 종종 값비싼 애플리케이션 서버가 필요합니다

JDO 사양은 JPA와 놀랍도록 유사한 API를 사용합니다. 그러나 JDO는 비관계형 데이터베이스를 지원하며 일부에서는 이 기능이 사양을 희석시킨다고 주장합니다

JPA는 위에 나열된 각 지속성 메커니즘의 최상의 기능을 결합합니다. JPA에서 엔터티를 생성하는 것은 직렬화 가능한 클래스를 생성하는 것만큼 간단합니다. JPA는 JDBC의 대용량 데이터 세트, 데이터 일관성, 동시 사용 및 쿼리 기능을 지원합니다. 객체 관계형 소프트웨어 및 객체 데이터베이스와 마찬가지로 JPA는 상속과 같은 고급 객체 지향 개념의 사용을 허용합니다. JPA는 JDBC의 대용량 데이터 세트, 데이터 일관성, 동시 사용 및 쿼리 기능을 지원합니다. 객체 관계형 소프트웨어 및 객체 데이터베이스와 마찬가지로 JPA에서는 상속과 같은 고급 객체 지향 개념을 사용할 수 있습니다. JPA는 JDO 및 EJB 2.x 엔터티와 같은 엄격한 사양에 의존하여 벤더 종속을 방지합니다. JPA는 관계형 데이터베이스에 중점을 둡니다. 그리고 JDO와 마찬가지로 JPA는 사용하기가 매우 쉽습니다.