私はORMをコンセプトとして使い慣れており、数年前に.NETプロジェクトでnHibernateを使用したことさえあります。ただし、JavaでのORMのトピックに追いついておらず、これらのツールを使用する機会もありませんでした。
しかし、今では、一連のレガシーWebサービスから離れようとして、アプリケーションの1つにいくつかのORMツールを使い始める機会があるかもしれません。
JPA仕様、Hibernateライブラリ自体で得られるもの、JDOが提供するものの違いを説明するのに苦労しています。
だから、私はこの質問が少々自由回答であることを理解していますが、私はいくつかの意見を得ることを望んでいました：
回答:
いくつかのメモ：
IMO、私は休止状態をお勧めします。
Hibernate固有の機能を使用する必要がある場合の対処法について、いくつかのコメント/質問がありました。これを見るには多くの方法がありますが、私のアドバイスは次のとおりです。
ベンダーとの連携の可能性に不安がない場合は、Hibernateと、意思決定におけるさまざまなベンダー固有の拡張機能を含む他のJPAおよびJDO実装の間で選択を行ってください。
ベンダーとの連携の可能性に不安があり、ベンダー固有の拡張機能に頼らずにJPAを使用できない場合は、JPAを使用しないでください。（JDOの同上）。
実際には、ベンダーとの連携で心配される量と、ベンダー固有の拡張機能が必要な量とをトレードオフする必要があるでしょう。
また、他の要因もあります。たとえば、あなた/スタッフがそれぞれのテクノロジーをどの程度理解しているか、製品のライセンスにかかるコスト、JDOとJPAの将来について何が起こるかについて、誰の話を信じているかなどです。
JDOのDataNucleus実装を必ず評価してください。Hibernateは人気が高いように見えましたが、すぐにそれが100％透過的な永続化ソリューションではないことに気付きました。警告が多すぎて、ドキュメントには「このような状況の場合は、このようにコードを記述する必要があります」で一杯であり、自由にモデリングとコーディングの面白さを取り除きました。JDOがコードやモデルを調整して「適切に機能する」ようにすることは決してありません。単純なPOJOを「メモリ内」でのみ使用するかのように設計してコーディングするだけで、透過的に永続化できます。
休止状態に対するJDO / DataNucleusのもう1つの利点は、ランタイムリフレクションのオーバーヘッドがすべてなく、ビルド時間のバイトコードの機能拡張を使用するため（大規模なプロジェクトのビルド時間に1秒を追加する可能性があるため）、メモリ効率が向上することです。 hibernateのランタイムリフレクションを利用したプロキシパターンよりも。
Hibernateでいらいらするかもしれないもう1つのことは、オブジェクトであると考えるものへの参照があるということです...それは多くの場合、オブジェクトの「プロキシ」です。バイトコード拡張の利点がない場合、プロキシパターンはオンデマンドロードを許可する必要があります（つまり、最上位のオブジェクトをプルするときにオブジェクトグラフ全体をプルしないようにします）。等しいとハッシュコードをオーバーライドする準備をしてください。参照していると思うオブジェクトは、多くの場合、そのオブジェクトの単なるプロキシです。
JDOでは得られない、Hibernateで得られる不満の例を次に示します。
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53
「回避策」にコーディングしたい場合は、Hibernateが最適です。すべての時間をモデリング、設計、コーディングに費やし、醜い回避策に費やさない、クリーンで純粋なオブジェクト指向のモデル駆動型開発に感謝する場合は、JDO / DataNucleusの評価に数時間を費やします。投資された時間は千倍に返済されます。
かなり長い間、DataNucleusはJDO永続性標準に加えてJPA永続性標準を実装しているため、HibernateからDataNucleusへの既存のJPAプロジェクトの移植は非常に簡単で、コード変更をほとんど行わなくても、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 /ベータマックスのような音が私に）。
JDOとそのリファレンス実装Datanucleusは、GoogleによるGAEへの採用とソースコード（http://sourceforge.net/projects/datanucleus/）での積極的な開発によって示されているように、明らかに死んではいません。
私はバイトコードの拡張によるJDOに関する多くの不満を目にしましたが、なぜそれが悪いのかについての説明はまだありません。
実際、NoSQLソリューションにますます取り憑かれるようになった世界では、JDO（およびデータニュークリアスの実装）の方がはるかに安全な賭けのようです。
JDO / Datanucleusの使用を開始し、db4oとmysqlを簡単に切り替えられるように設定しました。迅速な開発にはdb4oを使用すると便利です。DBスキーマについてあまり心配する必要はありません。その後、スキーマが安定してデータベースにデプロイされたら、それは重要です。後で、アプリケーションのすべてまたは一部をGAEにデプロイしたり、分散ストレージを利用したり、あまりリファクタリングを行わなくても、hbase / hadoop / cassandraを活用したりできると確信しています。
Datanucleusの使用を開始する際の最初のハードルは少しトリッキーだと感じました-datanucleus Webサイトのドキュメントにアクセスするのは少し難しいです-チュートリアルは私が思ったほど簡単にはたどりません。そうは言っても、最初の学習曲線を過ぎると、APIとマッピングに関するより詳細なドキュメントは非常に役立ちます。
答えは、それはあなたが望むものに依存します。私はむしろ、よりクリーンなコード、ベンダーロックイン、ポジョ指向、nosqlのオプションより人気のあるオプションが欲しいです。
他の大多数の開発者/羊と同じようにやっているという温かいうるさい感覚が必要な場合は、JPA /休止状態を選択してください。自分の分野でリードしたい場合は、JDO / Datanucleusを試してみて、自分で考えてください。
新しいプロジェクトにはどれを提案しますか？
どちらもお勧めしません！使用春のDAOのJdbcTemplateと一緒にStoredProcedure、RowMapperそしてRowCallbackHandler代わりに。
私自身のHibernateの個人的な経験では、事前に節約された時間は、予期しないカスケード更新の動作などの問題を理解してデバッグしようとする無限の日によって相殺される以上のものです。
リレーショナルDBを使用している場合は、コードに近づくほど、制御が強化されます。SpringのDAOレイヤーを使用すると、ボイラープレートコードの必要性を排除しながら、マッピングレイヤーを細かく制御できます。また、Springのトランザクションレイヤーに統合されているため、コードに侵入することなく、複雑なトランザクション動作を（AOPを介して）非常に簡単に追加できます（もちろん、Hibernateでもこれを取得できます）。
JDOが死んでいる
JDOは実際には死んでいないので、事実を確認してください。JDO 2.2は2008年10月にリリースされました。JDO2.3は開発中です。
これはApacheの下でオープンに開発されています。JPAのリリースよりも多くのリリースがあり、そのORM仕様は、JPA2が提案した機能よりもまだ先行しています。
JDOはJPAよりも高度な機能を備えていますhttp://db.apache.org/jdo/jdo_v_jpa.htmlを参照してください
私はJPAを使用しています（ApacheのOpenJPA実装は5年以上前のKODO JDOコードベースに基づいており、非常に高速で信頼性が高い）。仕様をバイパスするように指示する私見の誰もがあなたに悪いアドバイスをしています。私は時間を入れて、確実に報われました。JDOまたはJPAのいずれかを使用すると、最小限の変更でベンダーを変更できます（JPAにはormマッピングがあるため、ベンダーを変更する可能性については1日もかからない）。私のように100以上のテーブルがある場合、これは巨大です。さらに、クラスターごとのキャッシュ排除機能を備えたビルトインキャッシュを利用できます。SQL / Jdbcは高パフォーマンスのクエリに適していますが、透過的な永続性は、アルゴリズムとデータ入力ルーチンの記述にはるかに優れています。私のシステム全体で約16のSQLクエリしかありません（5万行以上のコード）。
私はこれを自分で調べたところ、2つの間の大きな違いを見つけることができません。大きな選択は、どの実装を使用するかだと思います。私はDataNucleusプラットフォームを検討しています。これは、データストアに依存しない両方の実装であるためです。
JDOが死んでいると言う人は誰でも、破壊的なFUDモンジャーであり、彼らはそれを知っています。
JDOは健在です。仕様は、はるかに若い制約のあるJPAよりもさらに強力で、成熟しており、高度です。
JPA標準で利用可能なものだけに制限したい場合は、JPAに書き込み、DataNucleusをJPAの他の実装よりも高性能で透過的な永続性実装として使用できます。もちろん、JDOがもたらすモデリングの柔軟性と効率が必要な場合は、DataNucleusもJDO標準を実装します。
同じプロジェクトでHibernate（JPA実装）とJPOX（JDO実装）を使用しました。JPOXは問題なく機能しましたが、かなり迅速にバグに遭遇しました。XAトランザクションの再生に問題がありました。JDOオブジェクトからデータベーススキーマを生成していました。それは毎回データベースに接続したかったのですが、Oracle接続が機能していない場合は面倒です。
その後、Hibernateに切り替えました。しばらくの間純粋なJPAを使用するだけでいじくり回しましたが、マッピングを行うにはHibernate固有の機能のいくつかを使用する必要がありました。複数のデータベースで同じコードを実行するのは非常に簡単です。Hibernateはオブジェクトを積極的にキャッシュしたり、奇妙なキャッシュ動作をしたりすることがあります。Hibernateが処理できないいくつかのDDLコンストラクトがあるため、データベースを初期化するために実行される追加のファイルで定義されます。私がHibernateの問題に遭遇したとき、多くの場合、同じ問題に遭遇した多くの人がいて、ソリューションの検索が簡単になります。最後に、Hibernateは適切に設計され、信頼できるようです。
他の一部の回答者は、SQLの使用のみを提案しています。オブジェクトリレーショナルマッピングの真のキラーユースケースは、テストと開発です。大量のデータを処理するために構築されたデータベースは、通常、高価であり、またはインストールが困難です。テストは困難です。テストに使用できるメモリ内Javaデータベースはたくさんありますが、通常、本番環境では役に立ちません。実際の限られたデータベースを使用できることで、開発の生産性とコードの信頼性が向上します。
2012年5月に、JDO 3.0とDataNucleus 3.0を使用するサンプルWebAppを作成しました。https：//github.com/TorbenVesterager/BadAssWebAppのクリーン度を確認して ください。
データベースとJSONクライアントの両方にPOJOを使用しているので、多分それは少しきれいすぎるかもしれませんが、それは楽しいです:)
PS：いくつかのSuppressWarnings注釈が含まれています（IntelliJ 11で開発）