81

Struts2を使用してGoogleAppEngineでプロジェクトを開発したいと思います。データベースには、JPAとJDOの2つのオプションがあります。提案してくれませんか?どちらも私にとっては新しいものであり、私はそれらを学ぶ必要があります。だから私はあなたの返事の後に焦点を当てます。

ありがとう。

4

12 に答える 12

34

GAE / Jグーグルグループには、まさにこのことについてのいくつかの投稿があります。そこで検索して、人の意見を見てみます。上記の意見とは非常に異なるメッセージが表示されます。BigTableがRDBMSではないという事実にも注目してください。仕事に適したツールを使用する

于 2009-09-14T17:01:08.957 に答える
31

JPAはSunの永続性の標準であり、JDOはIMHOが死にかけています(実際には、死んでいますが、まだ動いています)。言い換えれば、JPAは長期的にはより良い投資であるように思われます。ですから、両方が初めての場合は、JPAを選択すると思います。

于 2009-09-13T17:20:09.700 に答える
24

DataNucleus自体によるJPAとJDOのこの比較を見たばかりです:-http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html目を見張る

于 2009-10-13T12:59:04.780 に答える
17

私はJDOの幸せなユーザーです。良い仕事を続けてください。

于 2010-01-28T17:06:58.197 に答える
12

JDOが死んだと主張する人々にはメリットがないわけではありません。Pro EJB 3 Java Persistence APIの本で読んだ内容は次のとおりです。「その後まもなく、Sunは、JDOが仕様保守モードに縮小され、Java Persistence APIがJDOと他の永続性ベンダーの両方から取得され、単一のサポートになることを発表しました。今後の標準。」著者のMikeKeithは、EJB3の共同仕様リーダーです。もちろん、彼はJPAの大きな支持者ですが、彼が嘘をつくほど偏見があるとは思えません。

確かに、本が出版されたとき、JDOはJPAよりも高度な技術的機能を備えていますが、ほとんどの主要ベンダーはJDOではなくJPAの背後で団結していました。IBM / OracleなどのEEの世界の大手企業も、RDBMSの大手ベンダーであるため、驚くことではありません。プロジェクトで非RDMBSよりも多くの顧客がRDMBSを使用しています。JDOは、GAEが大きな後押しをするまで死にかけていました。GAEデータストアはリレーショナルデータベースではないため、これは理にかなっています。一部のJPA機能は、集計クエリ、結合クエリ、多対多の関係など、bigtableでは機能しません。ところで、GAEはJDO 2.3をサポートしますが、JPA1.0のみをサポートします。GAEがターゲットクラウドプラットフォームである場合は、JDOをお勧めします。

于 2011-02-10T06:03:15.080 に答える
11

ちなみに、これはGoogle App Engine(GAE)であるため、Oracle/SunのルールではなくGoogleのルールを使用します。

その下では、JPAはGAEに適していないため、不安定であり、期待どおりに機能しません。どちらのグーグルもそれをサポートするつもりはありませんが、最低限です。

そして他の部分については、JDOはGAEで非常に安定しており、(ある程度)Googleによって十分に文書化されています。

ただし、Googleはそれらのいずれも推奨していません。

http://code.google.com/appengine/docs/java/datastore/overview.html

低レベルのAPIは最高のパフォーマンスを提供し、GAEはパフォーマンスがすべてです。

http://gaejava.appspot.com/

たとえば、10個のエンティティを追加します

Python:68ms

JDO:378ms

Java Native:30ms

于 2011-08-31T23:58:49.003 に答える
9

JDOとJPAの間の競争では、datanucleusのポスターにしか同意できません。

まず第一に、そしてまた最も重要なことに、datanucleusのポスターは彼らが何をしているのかを知っています。結局のところ、彼らは永続的なライブラリを開発しており、リレーショナル以外のデータモデル(Big Tableなど)に精通しています。hibernateの開発者がここにいたと確信しています。「コアライブラリを構築する際のすべての仮定はリレーショナルモデルと緊密に結合されており、hibernateはGAE用に最適化されていません」。

第二に、JPAは間違いなくより広く使用されており、公式のJava EEスタックの一部であることが少し役立ちますが、必ずしもそれが優れていることを意味するわけではありません。実際、JDOについて読むと、JPAよりも高いレベルの抽象化に対応しています。JPAは、RDBMSデータモデルと緊密に結合されています。

プログラミングの観点からは、JDO APIを使用する方がはるかに優れたオプションです。これは、概念的に妥協することがはるかに少ないためです。使用するプロバイダーが基盤となるデータベースをサポートしている場合は、理論的には任意のデータモデルに切り替えることができます。(実際には、GAEのオブジェクトに主キーを設定し、特定のデータベースプロバイダー(Googleなど)に接続するため、このような高レベルの透明性を実現することはめったにありません)。ただし、移行はさらに簡単になります。

第三に、Hibernate、Eclipse Link、さらにはGAEでSpringを使用できます。Googleは、アプリケーションの構築に使用したフレームワークを使用できるようにするために多大な努力を払ったようです。しかし、GAEアプリケーションをRDBMSで実行しているかのように構築するときに人々が気付くのは、速度が遅いということです。GAEの春は遅いです。このトピックに関するGoogleIOビデオをグーグルで検索して、それが真実であることを確認できます。

また、基準を遵守することは賢明なことであり、原則として私は称賛します。一方、Java EEスタックの一部であるJPAにより、人々はオプションの概念を失うことがあります。必要に応じて、JavaServerFacesもJavaEEスタックの一部であることを認識してください。そして、それはWebGUI開発のための信じられないほどきちんとしたソリューションです。しかし、結局のところ、なぜ人々、私がそう言うかもしれないより賢い人々が、この標準から逸脱し、代わりにGWTを使用するのでしょうか?

これらすべてにおいて、JPAにとって非常に重要なことが1つあることを述べなければなりません。それがGuiceとJPAの便利なサポートです。グーグルはこの時点でいつもほど賢くなく、今のところJDOをサポートしていないことに満足しているようです。私はまだ彼らがそれを買う余裕があると思います、そして最終的にGuiceはJDOも飲み込むでしょう...または多分そうではありません。

于 2012-07-14T15:48:55.900 に答える
7

JDOに移動します。経験がなくても習得するのは難しくなく、新しいスキルを身につけることができます!

于 2010-07-15T00:33:48.697 に答える
6

JDOこれを書いている時点で使用することについて私がひどいと思うのは、唯一の実装ベンダーでDatanucleusあり、その欠点は、次のような多くの問題につながる競争の欠如です。

  1. のようないくつかの側面についてのあまり詳細ではないドキュメントextensions
  2. あなたは通常、(ログをチェックしたことがありますか?それらを持っている理由があるかもしれません)のような作者から皮肉な応答を受け取り、そのような迷惑な応答を受け取ります
  3. 有益な時間内に質問に対する回答が得られない場合があります。7日以内に回答が得られた場合は、ここでも自分の幸運を考慮する必要があります。StackOverflow

私は常に誰かがJDO仕様を自分で実装し始めることを望んでいます、そうすれば彼らはコミュニティにもっともっとそしてうまくいけばもっと自由なDatanucleus注意を提供し、著者が商業的サポートだけを気にかけていると言っているのではなく、常にサポートの支払いを気にする必要はありません、しかし私はただ言っているだけです。

私は個人的に、作者はそれ自体にもコミュニティにもDatanucleus一切の義務を負わないと考えています。Datanucleus彼らはいつでもプロジェクト全体を落とすことができ、誰もそれを判断することはできません。それは彼らの努力と彼ら自身の財産です。しかし、あなたは自分が何に入っているのかを知っているべきです。ご存知のとおり、私たちの開発者の1人が使用するフレームワークを探す場合、フレームワークの作成者を罰したり命令したりすることはできませんが、その一方で、作業を完了する必要があります。そのフレームワークを書く時間があったら、そもそもなぜそれを探すのでしょうか?!

一方、JDOそれ自体には、オブジェクトのライフサイクルや、あまり直感的で一般的ではないものなど、いくつかの問題があります(私は思います)。

編集:オブジェクトライフサイクルメカニズムも適用されることがわかっJPAたので、標準のORM API(JPAまたはJDO)を使用する場合は、永続化されたエンティティのライフサイクル状態を処理することは避けられないようです。

私が最も気に入っているJDOのは、かなりの労力をかけずに任意のデータベース管理システムを操作できることです。

于 2013-01-28T18:46:02.593 に答える
3

GAE / Jは、年末までにMYSQLを追加する予定です。

于 2010-08-18T16:30:36.843 に答える
1

JPAは、標準化されたAPIとしてプッシュされているようで、最近EJB3.0で勢いを増しているため、進むべき道です。JDOは勢いを失ったようです。

于 2010-06-05T09:30:46.477 に答える
1

ない!

Objectifyを使用します。これは、より安価で(使用するリソースが少なく)、より高速であるためです。参考:http ://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectifyは、GoogleAppEngineデータストア用に特別に設計された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);
于 2013-07-04T23:37:27.213 に答える