Struts2로 Google App Engine에서 프로젝트를 개발하고 싶습니다. 데이터베이스의 경우 JPA와 JDO의 두 가지 옵션이 있습니다. 제발 제안 해 주 시겠어요? 둘 다 저에게 새롭고 배워야합니다. 그래서 나는 당신의 대답 후에 하나에 집중할 것입니다.
감사.
답변
JPA는 지속성에 대한 Sun의 표준이고 JDO는 IMHO 죽어 가고 있습니다 (실제로는 죽었지 만 여전히 움직이고 있습니다). 즉, JPA는 장기적으로 더 나은 투자 인 것 같습니다. 그래서 둘 다 나에게 처음이라면 JPA를 선택했을 것입니다.
답변
GAE / J Google 그룹에는 이에 대한 여러 게시물이 있습니다. 나는 거기를 검색하고 사람들의 의견을 볼 것입니다. 위에 표현 된 의견과는 매우 다른 메시지를 받게됩니다. 또한 BigTable이 RDBMS가 아니라는 사실에 주목하십시오. 작업에 적합한 도구 사용
답변
DataNucleus가 직접 JPA와 JDO를 비교 한 내용을 살펴 보았습니다.
http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html
눈을 뜨게하는 사람.
답변
저는 JDO의 행복한 사용자입니다. 좋은 일을 계속하십시오.
답변
JDO가 죽었다고 주장하는 사람들은 장점이 없습니다. Pro EJB 3 Java Persistence API 책에서 읽은 내용은 다음과 같습니다. “곧 Sun은 JDO가 사양 유지 관리 모드로 축소되고 Java Persistence API가 JDO 및 다른 지속성 공급 업체에서 가져와 단일 지원이 될 것이라고 발표했습니다. 앞으로 표준. “. 저자 Mike Keith는 EJB3의 공동 사양 리더입니다. 물론 그는 JPA의 큰 지지자이지만 거짓말을 할만큼 편견이있는 것 같지는 않다.
이 책이 출판되었을 때 JDO가 JPA보다 더 고급 기술 기능을 가지고 있음에도 불구하고 대부분의 주요 공급 업체가 JDO가 아닌 JPA 뒤에 통합 된 것은 사실입니다. IBM / Oracle과 같은 EE 세계의 대기업도 대형 RDBMS 벤더이기 때문에 놀라운 일이 아닙니다. 더 많은 고객이 프로젝트에서 비 RDMBS보다 RDMBS를 사용하고 있습니다. JDO는 GAE가 큰 도움을 줄 때까지 죽어 가고있었습니다. GAE 데이터 저장소가 관계형 데이터베이스가 아니기 때문에 의미가 있습니다. 집계 쿼리, 조인 쿼리, 소유 된 다 대다 관계와 같은 일부 JPA 기능은 bigtable에서 작동하지 않습니다. BTW, GAE는 JDO 2.3을 지원하고 JPA 1.0 만 지원합니다. GAE가 타겟 클라우드 플랫폼이라면 JDO를 추천하겠습니다.
답변
기록적으로는 Google App Engine (GAE)이므로 Oracle / Sun 규칙이 아닌 Google 규칙을 사용합니다.
그 아래에서 JPA는 GAE에 적합하지 않고 불안정하며 예상대로 작동하지 않습니다. Google은 지원할 의사가 없지만 최소한의 지원을 제공합니다.
그리고 다른 부분에서 JDO는 GAE에서 매우 안정적이며 Google에서 (일부 확장) 잘 문서화되어 있습니다.
그러나 Google은 이들 중 어느 것도 권장하지 않습니다.
http://code.google.com/appengine/docs/java/datastore/overview.html
저수준 API는 최고의 성능을 제공하며 GAE는 성능에 관한 것입니다.
예를 들어 엔티티 10 개를 추가합니다.
파이썬 : 68ms
JDO : 378ms
자바 네이티브 : 30ms
답변
JDO와 JPA 간의 경쟁에서 나는 데이터 핵 포스터에만 동의 할 수 있습니다.
우선, 가장 중요한 것은 datanucleus의 포스터가 그들이 무엇을하고 있는지 알고 있다는 것입니다. 그들은 결국 영구 라이브러리를 개발하고 있으며 관계형 이외의 데이터 모델 (예 : Big Table)에 익숙합니다. 나는 id가 hibernate에 대한 개발자가 여기에 있었다고 확신한다. 그는 “우리의 핵심 라이브러리를 구축 할 때 우리의 모든 가정은 관계형 모델과 밀접하게 결합되어 있으며, hibernate는 GAE에 최적화되어 있지 않다”고 말할 것이다.
둘째, JPA는 의심 할 여지없이보다 광범위하게 사용되며 공식 Java EE 스택의 일부가되는 데 도움이되지만 반드시 더 나은 것은 아닙니다. 사실 JDO는 JPA보다 더 높은 수준의 추상화에 해당합니다. JPA는 RDBMS 데이터 모델과 밀접하게 연결되어 있습니다.
프로그래밍 관점에서 볼 때 JDO API를 사용하는 것이 훨씬 더 나은 옵션입니다. 개념적으로 타협하는 것이 훨씬 적기 때문입니다. 사용하는 제공자가 기본 데이터베이스를 지원하는 경우 이론적으로 원하는 데이터 모델로 전환 할 수 있습니다. (실제로 GAE의 개체에 기본 키를 설정하고 특정 데이터베이스 공급자 (예 : google)에 연결되기 때문에 높은 수준의 투명성을 달성하는 경우는 거의 없습니다.) 그래도 마이그레이션하는 것이 더 쉬울 것입니다.
셋째, Hibernate, Eclipse Link 및 GAE와 함께 스프링을 사용할 수 있습니다. Google은 애플리케이션을 빌드하는 데 사용되는 프레임 워크를 사용할 수 있도록 많은 노력을 기울인 것 같습니다. 그러나 사람들이 마치 RDBMS에서 실행중인 것처럼 GAE 애플리케이션을 빌드 할 때 깨닫는 것은 속도가 느리다는 것입니다. GAE의 봄은 느립니다. 이 주제에 대한 Google IO 비디오를 검색하여 그것이 사실인지 확인할 수 있습니다.
또한 표준을 준수하는 것은 원칙적으로 박수를 보냅니다. 반면에 JPA는 Java EE 스택의 일부이기 때문에 사람들은 때때로 옵션 개념을 잃게됩니다. 원하는 경우 Java Server Faces도 Java EE 스택의 일부임을 인식하십시오. 그리고 웹 GUI 개발을위한 믿을 수 없을 정도로 깔끔한 솔루션입니다. 그러나 결국, 내가 그렇게 말할 수 있다면 더 똑똑한 사람들이이 표준에서 벗어나 대신 GWT를 사용하는 이유는 무엇입니까?
이 모든 과정에서 JPA에 매우 중요한 일이 하나 있다고 생각해야합니다. 그것은 Guice와 JPA에 대한 편리한 지원입니다. 이 시점에서 Google은 평소처럼 똑똑하지 않았으며 현재로서는 JDO를 지원하지 않는 것에 만족합니다. 나는 여전히 그들이 그것을 감당할 수 있다고 생각하고 결국 Guice는 JDO도 삼킬 것입니다.
