私は概念としての ORM に精通しており、数年前に .NET プロジェクトで nHibernate を使用したことさえあります。しかし、私は Java での ORM の話題についていけず、これらのツールを使用する機会がありませんでした。
しかし、一連のレガシー Web サービスから離れようとして、アプリケーションの 1 つにいくつかの ORM ツールを使い始める機会があるかもしれません。
JPA 仕様、Hibernate ライブラリ自体で得られるもの、および JDO が提供するものとの違いを説明するのに苦労しています。
したがって、この質問が少し自由回答であることは理解していますが、次の点について意見を求めたいと思っていました。
いくつかのメモ：
IMO、Hibernateをお勧めします。
Hibernate固有の機能を使用する必要がある場合に何をすべきかについて、いくつかのコメント/質問があります。これを見る方法はたくさんありますが、私のアドバイスは次のとおりです。
ベンダーとの提携の可能性を心配していない場合は、Hibernateと、意思決定におけるさまざまなベンダー固有の拡張機能を含む他のJPAおよびJDO実装のどちらかを選択してください。
ベンダーとの提携の可能性が心配で、ベンダー固有の拡張機能に頼らずにJPAを使用できない場合は、JPAを使用しないでください。（JDOの場合も同様）。
実際には、ベンダーとの提携によって心配している量と、ベンダー固有の拡張機能が必要な量とのトレードオフが必要になる可能性があります。
また、あなた/あなたのスタッフがそれぞれの技術をどれだけよく知っているか、製品のライセンスにかかる費用、JDOとJPAの将来に何が起こるかについてあなたが信じている話など、他の要因もあります。
JDOのDataNucleus実装を必ず評価してください。Hibernateは非常に人気があるように見えたので始めましたが、すぐに100％透過的な永続化ソリューションではないことに気づきました。注意点が多すぎて、ドキュメントは「このような状況になったら、このようにコードを作成する必要があります」でいっぱいです。これにより、自由にモデリングおよびコーディングする楽しみが失われました。JDOによって、コードやモデルが「正しく機能する」ように調整されたことは一度もありません。単純なPOJOを「メモリ内」でのみ使用するかのように設計およびコーディングできますが、透過的に永続化することはできます。
Hibernateに対するJDO/DataNucleusのもう1つの利点は、実行時のリフレクションオーバーヘッドがすべてなく、ビルド時のバイトコード拡張（大規模なプロジェクトのビルド時間に1秒追加される可能性がある）を使用するため、メモリ効率が高くなることです。 hibernateのランタイムリフレクションを利用したプロキシパターンよりも。
Hibernateで煩わしいと感じるかもしれないもう一つのことは、あなたがオブジェクトであると思うものへの参照があるということです...それはしばしばオブジェクトの「プロキシ」です。バイトコード拡張の利点がなければ、オンデマンドのロードを可能にするためにプロキシパターンが必要です（つまり、トップレベルのオブジェクトをプルするときにオブジェクトグラフ全体をプルしないようにします）。参照していると思われるオブジェクトは、多くの場合、そのオブジェクトの単なるプロキシであるため、equalsとハッシュコードをオーバーライドする準備をしてください。
JDOでは得られないHibernateで得られるフラストレーションの例を次に示します。
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53
'回避策'にコーディングするのが好きなら、確かに、Hibernateはあなたにぴったりです。モデリング、設計、コーディングにすべての時間を費やし、醜い回避策に時間を費やさない、クリーンで純粋なオブジェクト指向のモデル駆動型開発に感謝する場合は、JDO/DataNucleusの評価に数時間を費やしてください。投資した時間は1000倍返済されます。
かなり長い間、DataNucleusはJDO永続性標準に加えてJPA永続性標準を実装しているため、既存のJPAプロジェクトをHibernateからDataNucleusに移植するのは非常に簡単で、コードをほとんど変更せずにDataNucleusの上記のすべての利点を得ることができます。 、もしあれば。したがって、質問に関しては、特定の標準の選択、JPA（RDBMSのみ）とJDO（RDBMS +SQLなし+ODBMSes+その他）、DataNucleusは両方をサポートし、HibernateはJPAのみに制限されています。
ORMを選択する際に考慮すべきもう1つの問題は、ダーティチェックメカニズムの効率です。これは、現在のトランザクションで変更されたオブジェクトを更新するSQLを構築する必要がある場合、特にオブジェクトが多数ある場合に非常に重要になります。このSO回答には、Hibernateのダーティチェックメカニズムの詳細な技術的説明があります 。HIBERNATE挿入を使用したJPAは非常に遅い
私は最近、Java プロジェクトの永続化フレームワークを評価して選択しました。私の結果は次のとおりです。
私が見ているのは、JDOを支持するサポートは主に次のとおりです。
JPAを支持するサポートは主に次のとおりです。
明らかに JDO/Datanucleus を使用していない JPA 開発者から、JDO を使用しないという弱い議論を提供している多くの JPA 支持の投稿を見ています。
また、JDO に移行し、結果として非常に満足している JDO ユーザーからの投稿もたくさん見ています。
JPA の人気が高まっているのは、技術的に優れているというよりも、RDBMS ベンダーのサポートによるものと思われます。(私には VHS/Betamax のように聞こえます)。
JDO とその参照実装である Datanucleus は、Google が GAE に採用し、ソース コード (http://sourceforge.net/projects/datanucleus/) で活発に開発されていることからもわかるように、明らかに死んでいません。
バイトコード拡張による JDO に関する苦情を数多く見てきましたが、JDO が悪い理由についての説明はまだありません。
実際、NoSQL ソリューションにますます夢中になっている世界では、JDO (およびデータニュークリアスの実装) の方がはるかに安全な賭けのようです。
JDO/Datanucleus を使い始めたばかりで、db4o と mysql の使用を簡単に切り替えられるようにセットアップしました。迅速な開発で db4o を使用すると便利です。DB スキーマについてあまり心配する必要はありません。スキーマが安定したら、データベースにデプロイします。また、後でアプリケーションのすべて/一部を GAE にデプロイしたり、あまりリファクタリングしなくても、分散ストレージ/マップリデュース a hbase /hadoop / cassandra を利用したりできると確信しています。
Datanucleus を使い始める際の最初のハードルが少し難しいことがわかりました。datanucleus の Web サイトのドキュメントは少しわかりにくいです。そうは言っても、最初の学習曲線を過ぎたら、API とマッピングに関するより詳細なドキュメントは非常に優れています。
The answer is, it depends what you want. I would rather have cleaner code, no-vendor-lock-in, more pojo-orientated, nosql options verses more-popular.
If you want the warm fussy feeling that you are doing the same as the majority of other developers/sheep, choose JPA/hibernate. If you want to lead in your field, test drive JDO/Datanucleus and make your own mind up.
新しいプロジェクトのためにどちらを提案しますか？
どちらもお勧めしません！代わりに、SpringDAOをとJdbcTemplate一緒に使用します。StoredProcedureRowMapperRowCallbackHandler
私自身のHibernateでの個人的な経験では、事前に節約された時間は、予期しないカスケード更新動作などの問題を理解してデバッグするために費やす無限の日数によって相殺されます。
リレーショナルDBを使用している場合は、コードがそれに近いほど、より多くの制御が可能になります。SpringのDAOレイヤーを使用すると、マッピングレイヤーを細かく制御できると同時に、ボイラープレートコードが不要になります。また、Springのトランザクションレイヤーに統合されているため、コードに侵入することなく、複雑なトランザクション動作を（AOPを介して）非常に簡単に追加できます（もちろん、Hibernateでもこれを取得できます）。
JDOは死んでいます
JDOは実際には死んでいないので、事実を確認してください。JDO2.2は2008年10月にリリースされました。JDO2.3は開発中です。
これは、Apacheの下でオープンに開発されています。JPAよりも多くのリリースがあり、そのORM仕様は、JPA2で提案されている機能よりもまだ進んでいます。
JDO には JPA よりも高度な機能がありますhttp://db.apache.org/jdo/jdo_v_jpa.htmlを参照してください
私はJPA（5年以上前の非常に高速で信頼性の高いKODO JDOコードベースに基づくApacheのOpenJPA実装）を使用しています。仕様をバイパスするように言う人は、悪いアドバイスをしていることになります。私は時間を費やし、間違いなく報われました。JDO または JPA のいずれかを使用すると、最小限の変更でベンダーを変更できます (JPA には or マッピングがあるため、ベンダーを変更する可能性については 1 日もかかりません)。私のように100以上のテーブルがある場合、これは巨大です。さらに、クラスター単位のキャッシュ エビクションを備えたビルトイン キャッシングと、そのすべてが優れています。SQL/Jdbc は高パフォーマンスのクエリには適していますが、透過的な永続性は、アルゴリズムやデータ入力ルーチンを作成する場合にはるかに優れています。システム全体で約 16 個の SQL クエリしかありません (5 万行以上のコード)。
JDO は終わったと言う人は誰でも、アストロターフィングの FUD モンガーであり、彼らはそれを知っています。
JDOは健在です。この仕様は、はるかに新しく制約のある JPA よりも強力で、成熟しており、高度です。
JPA 標準で使用できるものだけに限定したい場合は、JPA に書き込み、DataNucleus をパフォーマンスの高い、JPA の他の実装よりも透過的な永続化実装として使用できます。もちろん、JDO がもたらすモデリングの柔軟性と効率性が必要な場合は、DataNucleus も JDO 標準を実装します。
私はこれを自分で調べてきましたが、2つの大きな違いを見つけることができません. 大きな選択は、どの実装を使用するかだと思います。私自身、DataNucleusプラットフォームはデータストアに依存しない両方の実装であるため、検討してきました。
同じプロジェクトで Hibernate (JPA 実装) と JPOX (JDO 実装) を使用しました。JPOX は問題なく動作しましたが、Java 5 言語機能が当時サポートされていなかったバグにすぐに遭遇しました。XA トランザクションの扱いに問題がありました。JDO オブジェクトからデータベース スキーマを生成していました。毎回データベースに接続したかったのですが、Oracle 接続が機能していない場合は面倒です。
次に、Hibernate に切り替えました。しばらく純粋な JPA を使ってみましたが、マッピングを行うために Hibernate 固有の機能をいくつか使用する必要がありました。複数のデータベースで同じコードを実行するのは非常に簡単です。Hibernate は、オブジェクトを積極的にキャッシュするか、時々奇妙なキャッシュ動作をするようです。Hibernate が処理できない DDL コンストラクトがいくつかあるため、それらはデータベースを初期化するために実行される追加のファイルで定義されます。私が Hibernate の問題に遭遇したとき、多くの人が同じ問題に遭遇したことが多く、解決策を探すのが簡単になりました。最後に、Hibernate は適切に設計され、信頼性が高いようです。
他の回答者の中には、SQL のみを使用することを提案した人もいます。オブジェクト リレーショナル マッピングの本当のキラー ユース ケースは、テストと開発です。大量のデータを処理するために構築されたデータベースは、通常、高価であるか、インストールが困難です。それらをテストするのは困難です。テストに使用できるメモリ内 Java データベースはたくさんありますが、通常は本番環境では役に立ちません。限られた実際のデータベースを使用できると、開発の生産性とコードの信頼性が向上します。
2012 年 5 月に、JDO 3.0 と DataNucleus 3.0 を使用するサンプル WebApp を作成しました 。
データベースと JSON クライアントの両方に POJO を使用しているため、少しきれいすぎるかもしれませんが、楽しいです :)
PS: いくつかの SuppressWarnings 注釈が含まれています (IntelliJ 11 で開発)