Hibernate vs JPA vs JDO - 각각의 장단점?[닫은]

https://stackoverflow.com/questions/530215

22-08-2019
|

문제

저는 ORM이라는 개념을 잘 알고 있으며, 몇 년 전에는 .NET 프로젝트에 nHibernate를 사용해 본 적도 있습니다.그러나 나는 Java의 ORM 주제를 따라잡지 못했고 이러한 도구를 사용할 기회도 없었습니다.

그러나 이제는 일련의 레거시 웹 서비스에서 벗어나려는 시도로 우리 애플리케이션 중 하나에 일부 ORM 도구를 사용할 기회가 생겼습니다.

나는 JPA 사양, Hibernate 라이브러리 자체에서 얻는 것, JDO가 제공하는 것 사이의 차이점을 말하기가 어렵습니다.

따라서 저는 이 질문이 다소 개방적이라는 것을 이해하지만 다음 사항에 대한 의견을 듣고 싶습니다.

각각의 장단점은 무엇입니까?
새로운 프로젝트에 대해 어떤 것을 제안하시겠습니까?
한 프레임워크와 다른 프레임워크를 사용하는 것이 합당한 특정 조건이 있습니까?

해결책

몇 가지 메모 :

JDO와 JPA는 모두 구현이 아닌 사양입니다.
아이디어는 코드를 표준 JPA 만 사용하도록 제한하는 경우 JPA 구현을 스왑 할 수 있다는 것입니다. (JDO를위한 ditto)
최대 절전 모드는 JPA의 이러한 구현으로 사용될 수 있습니다.
그러나 Hibernate는 JPA보다 위와 그 이상의 기능을 갖춘 기본 API를 제공합니다.

IMO, 나는 최대 절전 모드를 추천합니다.

당신이해야 할 일에 대한 의견 / 질문이있었습니다. 필요 최대 절전 모드 특이 적 기능을 사용합니다. 이것을 보는 방법에는 여러 가지가 있지만 내 조언은 다음과 같습니다.

공급 업체 타이 인의 전망에 걱정하지 않으면 최대 절전 모드 및 기타 JPA 및 JDO 구현 중에서 선택하십시오. 포함 의사 결정의 다양한 공급 업체 별 확장.
공급 업체 타이 인의 전망에 걱정이되고 공급 업체 별 확장에 의지하지 않고 JPA를 사용할 수 없다면 JPA를 사용하지 마십시오. (JDO를위한 ditto).

실제로, 당신은 아마도 트레이드 오프가 필요할 것입니다 얼마예요 공급 업체 타이 인 대 걱정이됩니다 얼마예요 해당 공급 업체 특정 연장이 필요합니다.

그리고 직원이 각 기술을 얼마나 잘 알고 있는지, 라이센스 비용에 얼마나 많은 비용이들 것인지, 그리고 JDO와 JPA의 미래에 어떤 일이 일어날 지에 대해 믿는 이야기와 같은 다른 요소도 있습니다.

다른 팁

JDO의 Datanucleus 구현을 평가하십시오. 우리는 그것이 인기있는 것처럼 보이기 때문에 최대 절전 모드로 시작했지만 곧 100% 투명한 지속성 솔루션이 아니라는 것을 깨달았습니다. 경고가 너무 많고 문서는 '이 상황이 있다면 이와 같은 코드를 작성해야합니다'로 가득 차 있습니다. JDO가 있습니다 절대 코드 나 모델을 조정하여 '제대로 작동'하게되었습니다. 나는 단순한 pojos를 마치 '메모리에서만 사용하는 것처럼 간단한 pojos를 디자인하고 코딩 할 수 있지만 투명하게 지속될 수 있습니다.

최대 절전 모드에 대한 JDO/Datanucleus의 또 다른 장점은 모든 실행 시간 반사 오버 헤드가없고 빌드 바이트 코드 향상 (대규모 프로젝트의 빌드 시간에 1 초를 추가 할 수 있음)을 사용하기 때문에 메모리 효율적이라는 것입니다. 최대 절전 모드의 런타임 반사 전원 프록시 패턴보다.

최대 절전 모드로 성가신 또 다른 것은 당신이 당신이 생각하는 것에 대한 참조가 대상이라고 생각한다는 것입니다. 그것은 종종 물체의 '프록시'입니다. 바이트 코드 향상의 이점이 없으면 프록시 패턴은 주문형로드를 허용하기 위해 필요합니다 (즉, 최상위 객체를 당기면 전체 객체 그래프를 당기지 않도록합니다). 당신이 참조하고 있다고 생각하는 객체는 종종 그 개체에 대한 대리일이기 때문에 평등과 해시 코드를 재정의 할 준비를하십시오.

다음은 JDO와 함께 얻지 못하는 최대 절전 모드로 얻을 수있는 좌절의 예입니다.

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

당신이 '해결 방법'으로 코딩하는 것을 좋아한다면, Hibernate는 당신을위한 것입니다. 모델링, 디자인 및 코딩에 모든 시간을 보내는 깨끗하고 순수한 객체 지향적 인 모델 중심 개발에 감사한다면 추악한 해결 방법에 해당하지 않으면 평가에 몇 시간을 보내십시오. JDO/Datanucleus. 투자 한 시간은 천 배가 상환됩니다.

2017 년 2 월 업데이트

꽤 오랫동안 Datanucleus의 Datanucleus는 JDO 지속 표준에 추가하여 JPA 지속성 표준을 구현하므로 기존 JPA 프로젝트를 최대 절전 모드에서 Datanucleus로 포팅하면 매우 간단해야하며 코드 변경이 거의 없습니다. , 만약에 어떠한. 따라서 문제의 관점에서, 특정 표준 JPA (RDBMS 만 해당) 대 JDO (RDBMS + SQL + ODBMSES + 기타)의 선택, DatAnucleus는 두 가지를 모두 지원하며, 최대 절전 모드는 JPA로만 제한됩니다.

최대 절전 모드 DB 업데이트의 성능

ORM을 선택할 때 고려해야 할 또 다른 문제는 더러운 검사 메커니즘의 효율성입니다. 이는 현재 트랜잭션에서 변경된 객체를 업데이트하기 위해 SQL을 구성해야 할 때 매우 중요합니다. 이에 대한 최대 절전 모드의 더러운 검사 메커니즘에 대한 자세한 기술 설명이 있습니다.최대 절전 모드가있는 JPA는 매우 느리게 삽입합니다

최근에 Java 프로젝트를위한 지속성 프레임 워크를 평가하고 선택했으며 내 연구 결과는 다음과 같습니다.

내가보고있는 것은 JDO 주로 :

비 SQL DataSources, DB4O, HBase, LDAP, BigTable, CouchDB (Cassandra 용 플러그인) 등을 사용할 수 있습니다.
SQL에서 비 SQL 데이터 소스로 쉽게 전환 할 수 있으며 그 반대로 그 반대가 가능합니다.
프록시 객체가 없으므로 hashcode () 및 equals () 구현과 관련하여 통증이 적습니다.
더 많은 pojo와 따라서 해결 방법이 필요합니다
더 많은 관계 및 현장 유형을 지원합니다

그리고 유리한 지원 JPA 주로 :

인기가 더 많은
JDO는 죽었다
바이트 코드 향상을 사용하지 않습니다

JDO/Datanucleus를 명확하게 사용하지 않은 JPA 개발자의 Pro-JPA 게시물이 JDO를 사용하지 않는 약한 인수를 제공합니다.

또한 JDO로 마이그레이션하고 결과적으로 훨씬 더 행복한 JDO 사용자의 많은 게시물을보고 있습니다.

JPA가 더 인기를 얻는 것과 관련하여, 이것은 부분적으로 RDBMS 공급 업체 지원이 기술적으로 우수하기보다는 기존 인 것 같습니다. (나에게 VHS/Betamax처럼 들린다).

JDO와 IT는 GOE에 대한 Google의 채택 및 소스 코드 (http://sourceforge.net/projects/datanucleus/)에 대한 Google의 채택으로 표시되는 것처럼 명백히 죽지 않았습니다.

나는 바이트 코드 향상으로 인해 JDO에 대한 많은 불만을 보았지만 왜 그것이 나쁜지에 대한 설명은 아직 없습니다.

실제로, NOSQL 솔루션에 의해 점점 더 집착되고있는 세상에서 JDO (및 Datanucleus 구현)는 훨씬 안전한 베팅으로 보입니다.

방금 JDO/Datanucleus를 사용하기 시작했고 DB4O와 MySQL을 사용하여 쉽게 전환 할 수 있도록 설정했습니다. 신속한 개발이 DB4O를 사용하는 데 도움이되며 DB 스키마에 대해 너무 걱정할 필요가없고 스키마가 데이터베이스에 배포되도록 안정화되면 일단 스키마가 안정화되면 도움이됩니다. 또한 나중에 응용 프로그램의 모든 /일부를 GAE에 배포하거나 분산 저장소 /MAP-REDUCE를 활용할 수 있다고 확신합니다.

Datanucleus를 시작하는 초기 장애물이 약간 까다로워 졌다는 것을 알았습니다. Datanucleus 웹 사이트의 문서는 조금 어렵습니다. 자습서는 내가 원하는만큼 쉽게 따라갈 수 없습니다. 그러나 API 및 매핑에 대한 더 자세한 문서는 초기 학습 곡선을 지나면 매우 좋습니다.

대답은, 당신이 원하는 것에 달려 있다는 것입니다. 차라리 더 깨끗한 코드, 비 벤더 로크 인, 더 많은 포가 지향적 인 NOSQL 옵션 구절이 더 인기가 있습니다.

다른 개발자/양과 동일하게하고 있다는 따뜻한 까다로운 느낌을 원한다면 JPA/Hibernate를 선택하십시오. 현장에서 이끌고 싶다면 JDO/Datanucleus를 테스트하고 자신의 마음을 올리십시오.

새로운 프로젝트를 위해 어떤 제안을 하시겠습니까?

나는 제안하지 않을 것이다! Spring Dao 's를 사용하십시오 JdbcTemplate 함께 StoredProcedure, RowMapper 그리고 RowCallbackHandler 대신에.

최대 절전 모드에 대한 저의 개인적인 경험은 최후의 절약 된 시간이 끝없는 날이 지나면 예상치 못한 캐스케이드 업데이트 업데이트 동작과 같은 문제를 이해하고 디버깅하려고 노력할 때까지 상쇄되는 것 이상이라는 것입니다.

관계형 DB를 사용하는 경우 코드가 가까워 질수록 더 많은 컨트롤이 있습니다. Spring의 DAO 층은 보일러 플레이트 코드가 필요하지 않고 매핑 레이어를 잘 제어 할 수 있습니다. 또한 Spring의 트랜잭션 계층에 통합되므로 코드에 침입하지 않고도 AOP를 통해 복잡한 트랜잭션 동작을 매우 쉽게 추가 할 수 있습니다 (물론 최대 절전 모드로도 얻습니다).

JDO는 죽었다

JDO는 실제로 죽지 않았으므로 사실을 확인하십시오. JDO 2.2는 2008 년 10 월에 출시되었습니다. JDO 2.3은 개발 중입니다.

이것은 Apache 아래에서 공개적으로 개발되었습니다. JPA보다 더 많은 릴리스가 있었으며 JPA2 제안 된 기능조차도 ORM 사양이 여전히 앞서 있습니다.

JDO는 JPA보다 고급 기능을 가지고 있습니다 http://db.apache.org/jdo/jdo_v_jpa.html

저는 JPA를 사용하고 있습니다 (Apache의 OpenJPA 구현은 5 세 이상이고 매우 빠르고 신뢰할 수있는 Kodo JDO 코드베이스를 기반으로합니다). IMHO 사양을 우회하도록 지시하는 사람은 누구나 나쁜 조언을 제공합니다. 나는 시간을 넣었고 확실히 보상을 받았다. JDO 또는 JPA를 사용하면 최소한의 변경으로 공급 업체를 변경할 수 있습니다 (JPA에는 ORM 매핑이있어서 하루도 채 걸리지 않으므로 공급 업체를 변경할 수 있습니다). 나와 같은 100 개 이상의 테이블이 있다면 이것은 엄청납니다. 또한 클러스터 별 캐시 퇴거와 모든 양호로 캐싱을 만들어냅니다. SQL/JDBC는 고성능 쿼리에 적합하지만 알고리즘 및 데이터 입력 루틴을 작성하는 데 투명한 지속성이 훨씬 뛰어납니다. 전체 시스템에는 약 16 개의 SQL 쿼리가 있습니다 (50k+ 코드 라인).

JDO가 죽었다고 말하는 사람은 누구나 FUD를 퍼뜨리는 사람이고 그들은 그것을 알고 있습니다.

JDO는 살아 있고 건강합니다.이 사양은 훨씬 더 젊고 제한된 JPA보다 훨씬 더 강력하고 성숙하며 고급입니다.

JPA 표준에서 사용할 수 있는 것만으로 제한하려면 JPA에 작성하고 DataNucleus를 고성능, JPA의 다른 구현보다 더 투명한 지속성 구현으로 사용할 수 있습니다.물론 JDO가 제공하는 모델링의 유연성과 효율성을 원한다면 DataNucleus는 JDO 표준도 구현합니다.

나는 이것을 직접 조사해 왔으며 둘 사이에 강한 차이를 찾을 수 없습니다. 큰 선택은 당신이 어떤 구현을 사용하는지 생각합니다. 나 자신을 위해 나는 그것을 고려하고있다 datanucleus 플랫폼은 둘 다의 데이터 스토어 불가지성 구현입니다.

동일한 프로젝트에서 최대 절전 모드 (JPA 구현) 및 JPOX (JDO 구현)를 사용했습니다. JPOX는 정상적으로 일했지만, 일부 Java 5 언어 기능은 당시에는 지원하지 않은 버그를 상당히 빨리 버그에 부딪쳤다. XA 트랜잭션에서 잘하는 데 문제가있었습니다. JDO 객체에서 데이터베이스 스키마를 생성하고있었습니다. Oracle 연결이 작동하지 않으면 성가신 시간마다 데이터베이스에 연결하고 싶었습니다.

그런 다음 최대 절전 모드로 전환했습니다. 우리는 잠시 동안 순수한 JPA를 사용하는 것만으로 놀랐지만, 일부 최대 절전 모드 특정 기능을 사용하여 매핑을 수행해야했습니다. 여러 데이터베이스에서 동일한 코드를 실행하는 것은 매우 쉽습니다. 최대 절전 모드는 물체를 적극적으로 캐시하거나 때때로 이상한 캐싱 동작을 갖는 것 같습니다. 최대 절전 모드가 처리 할 수없는 몇 가지 DDL Constructs가 있으므로 데이터베이스를 초기화하기 위해 실행되는 추가 파일에 정의됩니다. 최대 절전 모드 문제에 빠지면 종종 같은 문제를 해결하는 많은 사람들이있어 솔루션을위한 인터넷 검색을 더 쉽게 할 수 있습니다. 마지막으로 최대 절전 모드는 잘 설계되고 신뢰할 수있는 것 같습니다.

다른 응답자들은 SQL을 사용하는 것을 제안했습니다. 객체 관계형 매핑의 실제 킬러 사용 사례는 테스트 및 개발입니다. 대량의 데이터를 처리하기 위해 구축 된 데이터베이스는 일반적으로 비싸거나 설치하기가 어렵습니다. 그들은 테스트하기가 어렵습니다. 테스트하는 데 사용할 수 있지만 일반적으로 생산에는 쓸모없는 메모리 인 Java 데이터베이스가 많이 있습니다. 실제하지만 제한된 데이터베이스를 사용할 수 있으면 개발 생산성과 코드 안정성이 향상됩니다.

2012 년 5 월 JDO 3.0 & Datanucleus 3.0을 사용하는 샘플 웹 앱을 만들었습니다. 얼마나 깨끗한 지 살펴보십시오.https://github.com/torbenvesterager/badasswebapp

데이터베이스와 JSON 클라이언트 모두에 pojos를 사용하기 때문에 너무 깨끗 할 수도 있지만 재미 있습니다. :)

추신 : 몇 가지 억제 주석이 포함되어 있습니다 (Intellij 11에서 개발)

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow