저는 ORM을 개념으로 잘 알고 있으며 몇 년 전 .NET 프로젝트에 nHibernate를 사용해 왔습니다. 그러나 Java의 ORM 주제를 따라 가지 않았으며 이러한 도구를 사용할 기회가 없었습니다.
그러나 이제는 일련의 레거시 웹 서비스에서 벗어나기 위해 응용 프로그램 중 하나에 일부 ORM 도구를 사용하기 시작할 수 있습니다.
JPA 사양, Hibernate 라이브러리 자체로 얻을 수있는 것 및 JDO가 제공하는 것 사이의 차이점을 알려주는 데 어려움을 겪고 있습니다.
그래서 나는이 질문이 약간 개방적이라는 것을 알고 있지만 다음과 같은 의견을 얻고 자했습니다.
답변:
몇 가지 참고 사항 :
IMO, 나는 최대 절전 모드를 추천합니다.
일부 댓글 / 당신이 경우에 당신이 무엇을해야하는지에 대한 질문이 있었다 필요가 최대 절전 모드 - 특정 기능을 사용 할 수 있습니다. 이것을 보는 많은 방법이 있지만, 나의 충고는 :
벤더 연계 가능성에 대해 걱정하지 않는다면, Hibernate와 의사 결정의 다양한 벤더별 확장을 포함 하여 다른 JPA 및 JDO 구현 중에서 선택 하십시오.
공급 업체 연계 가능성에 대해 걱정하고 공급 업체별 확장을 사용하지 않고 JPA를 사용할 수없는 경우 JPA를 사용하지 마십시오. (JDO 용 Ditto).
실제로, 당신은 아마 트레이드 오프를해야합니다 얼마나 많은 당신이 대 타이 인 공급 업체에서 걱정 얼마나 당신이 그 벤더의 특정 확장이 필요합니다.
또한 직원 / 각 직원이 각 기술을 얼마나 잘 알고 있는지, 라이센스 비용이 얼마나 드는지, 향후 JDO 및 JPA에 대해 향후 어떤 일이 일어날 지에 대한 이야기와 같은 다른 요인들도 있습니다.
JDO의 DataNucleus 구현을 평가하십시오. 우리는 Hibernate로 시작하여 매우 인기가 있었지만 곧 100 % 투명한 지속성 솔루션이 아니라는 것을 깨달았습니다. 주의해야 할 사항이 너무 많으며 설명서에는 '이 상황이 발생하면 이와 같이 코드를 작성해야합니다.'라는 자유롭게 모델링과 코딩의 재미를 없앨 수 있습니다. JDO는 코드 나 모델이 '제대로 작동'되도록 조정 한 적이 없습니다 . 단순한 POJO를 '메모리에서'만 사용하는 것처럼 디자인하고 코딩 할 수 있지만 투명하게 유지할 수 있습니다.
최대 절전 모드에 비해 JDO / DataNucleus의 또 다른 장점은 모든 런타임 반영 오버 헤드가없고 빌드 타임 바이트 코드 향상 (대규모 프로젝트의 빌드 시간에 1 초 추가)을 사용하기 때문에 메모리 효율성이 높다는 것입니다. 최대 절전 모드의 런타임 반영 기반 프록시 패턴보다.
Hibernate에서 짜증나는 또 다른 것은 객체라고 생각하는 것에 대한 참조가 객체의 '프록시'라는 것입니다. 바이트 코드 향상의 이점없이 요청시로드를 허용하려면 프록시 패턴이 필요합니다 (즉, 최상위 레벨 오브젝트를 가져올 때 전체 오브젝트 그래프를 가져 오지 마십시오). 참조한다고 생각하는 객체는 종종 해당 객체의 프록시 일 뿐이므로 equals와 hashcode를 재정의 할 준비를하십시오.
다음은 JDO에서 얻을 수없는 Hibernate에서 얻을 수있는 좌절의 예입니다.
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53
'해결 방법'으로 코딩하는 것을 좋아한다면 최대 절전 모드가 적합합니다. 모델링, 디자인 및 코딩에 모든 시간을 소비하고 추악한 해결 방법에 대한 시간을 소비하지 않는 깨끗하고 순수한 객체 지향 모델 중심 개발에 감사 한 경우 JDO / DataNucleus 평가에 몇 시간을 소비하십시오 . 투자 한 시간은 천 배로 상환됩니다.
꽤 오랫동안 DataNucleus는 JDO 지속성 표준 외에도 JPA 지속성 표준을 구현하므로 기존 JPA 프로젝트를 Hibernate에서 DataNucleus로 포팅하는 것은 매우 간단해야하며 코드 변경이 거의없이 위에서 언급 한 DataNucleus의 이점을 모두 얻을 수 있습니다. , 만약에 어떠한. 따라서 질문, 특정 표준, JPA (RDBMS 전용) 대 JDO (RDBMS + SQL 없음 + ODBMSes + 기타)의 선택과 관련하여 DataNucleus는 두 가지를 모두 지원하며 최대 절전 모드는 JPA로만 제한됩니다.
ORM을 선택할 때 고려해야 할 또 다른 문제는 더티 검사 메커니즘의 효율성입니다. 이는 현재 트랜잭션에서 변경된 오브젝트를 업데이트하기 위해 SQL을 구성해야 할 때, 특히 많은 오브젝트가있을 때 매우 중요합니다. 이 SO 답변에는 Hibernate의 더티 검사 메커니즘에 대한 자세한 기술 설명이 있습니다. HIBERNATE 인서트가 매우 느린 JPA
최근에 Java 프로젝트의 지속성 프레임 워크를 평가하고 선택했으며 결과는 다음과 같습니다.
내가보고있는 것은 JDO 를지지하는 지원 이 주로 다음과 같습니다.
JPA 를지지하는 지원 은 주로 다음과 같습니다.
JDO를 사용하지 않는 것에 대한 약한 주장을 제공하는 JDO / Datanucleus를 분명히 사용하지 않은 JPA 개발자의 많은 pro-JPA 게시물이 표시됩니다.
또한 JDO로 마이그레이션하여 결과적으로 훨씬 행복한 JDO 사용자로부터 많은 게시물을보고 있습니다.
JPA가 더 널리 사용되는 것과 관련하여 이는 기술적으로 우수하지 않고 RDBMS 공급 업체 지원으로 인해 발생한 것으로 보입니다. (VHS / Betamax와 같은 소리가 나에게 들립니다).
JDO와 그것의 참조 구현 Datanucleus는 구글이 GAE를 위해 그것을 채택하고 소스 코드 (http://sourceforge.net/projects/datanucleus/)에서 적극적으로 개발 한 것처럼 명백히 죽지 않았다.
바이트 코드 향상으로 인해 JDO에 대한 많은 불만이 있었지만 왜 나쁜지에 대한 설명은 없습니다.
실제로 NoSQL 솔루션에 점점 더 집착하는 세상에서 JDO (및 데이터 핵 구현)는 훨씬 더 안전한 방법으로 보입니다.
방금 JDO / Datanucleus를 사용하기 시작했으며 db4o와 mysql을 쉽게 전환 할 수 있도록 설정했습니다. db4o를 사용하는 빠른 개발에 도움이되고 데이터베이스에 배포하기 위해 스키마가 안정화되면 DB 스키마에 대해 너무 걱정할 필요가 없습니다. 또한 나중에 애플리케이션의 전체 / 일부를 GAE에 배포하거나 너무 많은 리팩토링없이 분산 스토리지 / 맵 감소를 활용하여 라하베이스 / 하둡 / 카산드라를 줄일 수 있다고 확신합니다.
Datanucleus를 시작하는 초기 장애물이 조금 까다로웠다는 것을 알았습니다. datanucleus 웹 사이트의 문서는 조금 다루기가 어렵습니다. 튜토리얼은 내가 좋아하는 것처럼 쉽게 따라갈 수 없습니다. 그러나 API 및 매핑에 대한 자세한 문서는 초기 학습 곡선을 벗어나면 매우 좋습니다.
답은 원하는 것에 달려 있습니다. 오히려 더 깨끗한 코드, 벤더 잠금, 포지 지향, nosql 옵션이 더 대중적입니다.
다른 개발자 / 양의 대다수와 같은 따뜻한 느낌을 원한다면 JPA / 최대 절전 모드를 선택하십시오. 현장에서 리드하려면 JDO / Datanucleus 드라이브를 테스트하고 마음을 정하십시오.
새로운 프로젝트를 제안 하시겠습니까?
나는 둘 다 제안하지 않을 것이다! 사용 스프링 DAO의 JdbcTemplate와 함께 StoredProcedure, RowMapper그리고RowCallbackHandler 대신.
Hibernate에 대한 저 자신의 개인적인 경험은 예기치 않은 계단식 업데이트 동작과 같은 문제를 이해하고 디버깅하려고 노력하는 데 줄을 서서 끝날 것입니다.
관계형 DB를 사용하는 경우 코드가 코드에 가까울수록 더 많이 제어 할 수 있습니다. Spring의 DAO 레이어는 매핑 코드를 세밀하게 제어하면서 상용구 코드가 필요하지 않습니다. 또한 Spring의 트랜잭션 계층에 통합되어 코드에 침입하지 않고도 복잡한 트랜잭션 동작을 AOP를 통해 쉽게 쉽게 추가 할 수 있습니다 (물론 Hibernate로도 얻을 수 있습니다).
JDO가 죽었다
JDO는 실제로 죽지 않았으므로 사실을 확인하십시오. JDO 2.2는 2008 년 10 월에 출시되었습니다. JDO 2.3은 개발 중입니다.
이것은 Apache에서 공개적으로 개발되었습니다. JPA보다 많은 릴리스가 있으며 ORM 사양은 여전히 JPA2가 제안한 기능보다 앞서 있습니다.
JDO는 JPA보다 고급 기능을 가지고 있습니다. http://db.apache.org/jdo/jdo_v_jpa.html
JPA (아파치의 OpenJPA 구현은 5 세 이상이고 매우 빠르고 신뢰할 수있는 KODO JDO 코드베이스를 기반으로합니다)를 사용하고 있습니다. IMHO가 사양을 우회하도록 지시하는 사람은 나쁜 조언을합니다. 나는 시간을 투자했고 확실히 보상을 받았다. JDO 또는 JPA를 사용하면 최소한의 변경으로 공급 업체를 변경할 수 있습니다 (JPA에는 orm 맵핑이 있으므로 공급 업체를 변경하기 위해 하루도 채 걸리지 않습니다). 내가하는 것처럼 100 + 테이블이 있다면 이것은 거대합니다. 또한 클러스터 방식의 캐시 제거 기능과 모든 기능을 갖춘 캐싱 기능을 내장하고 있습니다. SQL / Jdbc는 고성능 쿼리에는 적합하지만 투명한 지속성은 알고리즘 및 데이터 입력 루틴 작성에 훨씬 뛰어납니다. 전체 시스템에 약 16 개의 SQL 쿼리 만 있습니다 (50k + 코드 라인).
나는 이것을 직접 조사해 왔으며 둘 사이의 큰 차이점을 찾을 수 없습니다. 가장 큰 선택은 사용하는 구현입니다. 나 자신을 위해 DataNucleus 플랫폼은 데이터 저장소와 무관하게 두 가지를 모두 구현하므로 고려하고 있습니다.
JDO가 죽었다고 말하는 사람은 누구나 야심 찬 FUD 상인이며 그것을 알고 있습니다.
JDO는 살아 있고 훌륭합니다. 이 사양은 훨씬 젊고 제한된 JPA보다 훨씬 강력하고 성숙하며 고급입니다.
JPA 표준에서 사용 가능한 것만으로 자신을 제한하려는 경우 JPA에 작성하고 DataNucleus를 다른 JPA 구현보다 고성능의 투명한 지속성 구현으로 사용할 수 있습니다. 물론 DataNucleus는 JDO가 제공하는 모델링의 유연성과 효율성을 원할 경우 JDO 표준도 구현합니다.
동일한 프로젝트에서 Hibernate (JPA 구현) 및 JPOX (JDO 구현)를 사용했습니다. JPOX는 정상적으로 작동했지만 당시에는 지원하지 않는 Java 5 언어 기능이있는 버그가 상당히 빨리 발생했습니다. XA 트랜잭션을 잘 플레이하는데 문제가있었습니다. JDO 객체에서 데이터베이스 스키마를 생성하고있었습니다. 오라클 연결이 작동하지 않으면 성가신 매번 데이터베이스에 연결하려고했습니다.
그런 다음 최대 절전 모드로 전환했습니다. 우리는 잠시 동안 순수한 JPA를 사용하여 놀았지만 매핑을 수행하기 위해 일부 Hibernate 특정 기능을 사용해야했습니다. 여러 데이터베이스에서 동일한 코드를 실행하는 것은 매우 쉽습니다. 최대 절전 모드는 개체를 적극적으로 캐시하거나 때로는 이상한 캐싱 동작을하는 것 같습니다. Hibernate가 처리 할 수없는 몇 가지 DDL 구조가 있으므로 데이터베이스를 초기화하기 위해 실행되는 추가 파일에 정의되어있다. 최대 절전 모드 문제를 겪을 때 종종 같은 문제가 발생하여 솔루션에 대한 인터넷 검색을 쉽게하는 사람들이 많이 있습니다. 마지막으로, 최대 절전 모드는 잘 설계되고 신뢰할 수있는 것 같습니다.
다른 응답자는 SQL 사용을 제안했습니다. 객체 관계형 매핑의 실제 킬러 사용 사례는 테스트 및 개발입니다. 많은 양의 데이터를 처리하기 위해 구축 된 데이터베이스는 일반적으로 비싸거나 설치하기가 어렵습니다. 테스트하기가 어렵습니다. 테스트에 사용할 수있는 인 메모리 Java 데이터베이스는 많지만 일반적으로 프로덕션에는 쓸모가 없습니다. 실제이지만 제한된 데이터베이스를 사용할 수 있으면 개발 생산성과 코드 안정성이 향상됩니다.
2012 년 5 월에 JDO 3.0 및 DataNucleus 3.0을 사용하는 샘플 WebApp을 작성했습니다. 얼마나 깨끗한 지 살펴보십시오. https://github.com/TorbenVesterager/BadAssWebApp
데이터베이스와 JSON 클라이언트 모두에 POJO를 사용하기 때문에 약간 깨끗합니다.하지만 재미 있습니다 :)
PS : SuppressWarnings 주석이 포함되어 있습니다 (IntelliJ 11에서 개발).