Struts2を使用して、Google App Engineでプロジェクトを開発します。データベースには、JPAとJDOの2つのオプションがあります。提案してくれませんか?両方とも私にとって新しいものであり、私はそれらを学ぶ必要があります。だから私はあなたの返事の後に一つに焦点を当てます。
ありがとう。
JPAはSunの永続性の標準で、JDOは死にかけています(実際には死んでいますが、まだ動いています)。言い換えれば、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の共同仕様リーダーです。彼は嘘をつくのに十分な偏見がある。
JDOにはJPAよりも高度な技術的機能がありますが、この本が出版されたとき、ほとんどの主要ベンダーはJDOではなくJPAの背後に統合されていました。 IBM/OracleなどのEEの世界の大企業も大きなRDBMSベンダーであるため、驚くことではありません。 RDMBSを使用している顧客は、プロジェクトで非RDMBSよりも多くなっています。 GAEが大きく後押しするまでJDOは死にかけていました。 GAEデータストアはリレーショナルデータベースではないため、理にかなっています。集約クエリ、結合クエリ、所有される多対多の関係など、一部のJPA機能はbigtableで動作しません。ところで、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エンティティを追加します
Python:68ms
JDO:378ms
Javaネイティブ:30ms
JDOとJPAの競合では、datanucleusのポスターにのみ同意できます。
まず第一に、そして最も重要なこととして、datanucleusのポスターは彼らが何をしているかを知っています。彼らは結局、永続的なライブラリを開発し、リレーショナル以外のデータモデルに精通しています。大きなテーブル。 hibernateの開発者であるidはここにいると確信しています。「コアライブラリを構築する際のすべての前提はリレーショナルモデルに密接に結合されており、hibernateはGAEに最適化されていません」。
第二に、JPAは間違いなくより広く使用されており、公式のJava EEスタックの一部であるため少し助けになりますが、必ずしもそれが優れていることを意味するわけではありません。 JPAはRDBMSデータモデルと密結合しているため、JPAよりも高い抽象化レベルに対応しています。
プログラミングの観点から見ると、JDO APIを使用する方がはるかに優れたオプションです。なぜなら、概念的に妥協することはずっと少ないからです。使用するプロバイダーが基礎となるデータベースをサポートしていれば、理論的には任意のデータモデルに切り替えることができます。 (実際には、GAEのオブジェクトに主キーを設定し、特定のデータベースプロバイダー(googleなど)に結び付けることに気付くため、このような高レベルの透明度を達成することはめったにありません)。ただし、移行は依然として簡単です。
3番目に、Hibernate、Eclipse Link、さらにはGAEを使用できます。 Googleは、アプリケーションの構築に使用しているフレームワークを使用できるようにするために多大な努力を払ったようです。しかし、RDBMS上で実行されているかのようにGAEアプリケーションを構築するときに人々が気付くのは、遅いということです。 GAEの春は遅いです。このトピックに関するGoogle IOビデオをグーグル検索して、それが正しいことを確認できます。
また、標準に従うことは賢明なことであり、原則として私は賞賛します。一方、JPAはJava EEスタックの一部であるため、人々はオプションの概念を失うことがあります。その場合、Java = Server FacesはJava EEスタックの一部でもあります。そして、Web GUI開発のための信じられないほど整然としたソリューションです。しかし、結局、人々、私がそう言うなら賢い人々はなぜですか、この標準から逸脱し、代わりにGWTを使用しますか?
このすべてにおいて、JPAには非常に重要なことが1つあります。それがGuiceとJPAの便利なサポートです。グーグルはこの時点ではいつものように賢くなく、コンテンツであるようだ。今のところJDOをサポートしていない。私はまだ彼らがそれを買う余裕があると思います、そして、結局、Guiceは同様にJDOを飲み込むでしょう...または多分そうではありません。
JDOを起動します。経験がなくても、習得するのは難しくありません。新しいスキルが身に付きます。
これを書いている時点でJDO
を使用することについて恐ろしいのは、実装ベンダーがDatanucleus
だけであり、その欠点は次のような多くの問題につながる競争の欠如であるということです。
extensions
のようないくつかの側面に関するあまり詳細ではないドキュメントStackOverflow
私は常に誰かがJDO
仕様の実装を開始することを望んでいます。そうすれば、彼らはより多くの、そしてできればもっと多くのことを提供するかもしれません無料コミュニティへの注意Datanucleus
作者は商用サポートのみを気にしていると言っているのではなく、サポートにお金を払っていますが、私はただ言っています。
私は個人的にはDatanucleus
作者にはDatanucleus
自体にもコミュニティにも義務がないと考えています。彼らはいつでもプロジェクト全体をドロップすることができ、誰も彼らのために彼らを判断することはできません、それは彼らの努力と彼ら自身の財産です。しかし、あなたは何に興味を持っているかを知っている必要があります。ご覧のように、開発者の1人が使用するフレームワークを探すとき、フレームワークの作成者を罰したり命令したりすることはできませんが、一方で、作業を完了する必要があります!そのフレームワークを書く時間があるなら、そもそもなぜフレームワークを探すのでしょうか?!
一方、JDO
自体には、オブジェクトのライフサイクルや非常に直感的で一般的ではないものなど、いくつかの問題があります(私は思う)。
編集:JPA
がオブジェクトライフサイクルメカニズムを実施することもわかっているので、標準のORM API(つまりJPA
)を使用する場合、永続化されたエンティティのライフサイクル状態を処理することは避けられないようですまたはJDO
)
JDO
で最も気に入っているのは、あらゆるデータベース管理システムをかなりの労力なしで使用できることです。
GAE/Jは、年末までにMYSQLを追加する予定です。
どちらでもない!
Objectifyを使用します。これは、安価で(使用するリソースが少ない)、高速であるためです。参考: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectifyは、Google App Engineデータストア用に特別に設計されたJavaデータアクセス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);
JPAは、標準化されたAPIとしてプッシュされているように思われ、最近EJB3.0で勢いを得ているようです。JDOはSteamを失ったようです。