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도 삼킬 것입니다.
JDO이 글을 쓰는 시점에서 사용하는 것이 끔찍하다고 생각 하는 것은 유일한 구현 벤더 Datanucleus이며 그 단점은 경쟁이 부족하여 다음과 같은 수많은 문제가 발생한다는 것입니다.
extensionsStackOverflow나는 항상 누군가가 JDO직접 사양을 구현하기를 바라고 있습니다. 그러면 작성자가 상업적 지원에만 관심이 있다고 말하는 것이 아니라 커뮤니티에 더 많은 무료 관심을 제공하고 지원 비용을 항상 Datanucleus신경 쓰지 않을 것입니다. , 그러나 나는 단지 말하는 것입니다.
개인적으로 Datanucleus저자는 Datanucleus자신이나 커뮤니티에 대해 어떠한 의무도 없다고 생각 합니다. 그들은 언제든지 전체 프로젝트를 중단 할 수 있으며 아무도 그것을 판단 할 수 없습니다. 그것은 그들의 노력과 자신의 재산입니다. 그러나 당신은 당신이 무엇을 얻고 있는지 알아야합니다. 우리 개발자 중 한 명이 사용할 프레임 워크를 찾을 때 프레임 워크 작성자를 처벌하거나 명령 할 수는 없지만 다른 한편으로는 작업을 완료해야합니다! 그 프레임 워크를 작성할 시간이 있다면 왜 처음부터 하나를 찾겠습니까?!
다른 한편으로, JDO그 자체는 매우 직관적이고 일반적이지 않은 (제 생각에) 객체 수명주기와 같은 몇 가지 복잡한 문제를 가지고 있습니다.
편집 : 이제 JPA개체 수명주기 메커니즘을 적용한다는 것을 알고 있으므로 표준 ORM API (예 : JPA또는 JDO) 를 사용하려는 경우 지속되는 개체 수명주기 상태를 처리하는 것이 불가피한 것처럼 보입니다.
내가 가장 좋아하는 것은 JDO상당한 노력없이 모든 데이터베이스 관리 시스템으로 작업 할 수있는 능력입니다.
GAE / J는 연말 이전에 MYSQL을 추가 할 예정입니다.
JPA는 표준화 된 API로 밀려 나고 최근에 EJB3.0에서 추진력을 얻고있는 것처럼가는 길입니다. JDO는 힘을 잃은 것 같습니다.
둘 다!
저렴하고 (더 적은 리소스 사용) 더 빠르기 때문에 Objectify를 사용하십시오. 참고 : http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectify는 Google App Engine 데이터 저장 소용으로 특별히 설계된 자바 데이터 액세스 API입니다. 그것은 "중간 지대"를 차지합니다. JDO 또는 JPA보다 사용하기 쉽고 투명하지만 저수준 API보다 훨씬 편리합니다. Objectify는 초보자가 즉시 생산성을 발휘할 수 있도록 설계되었지만 GAE 데이터 저장소의 모든 기능을 제공합니다.
Objectify를 사용하면 유형이 지정된 개체를 유지, 검색, 삭제 및 쿼리 할 수 있습니다.
@Entity
class Car {
@Id String vin; // Can be Long, long, or String
String color;
}
ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);