Hibernate vs JPA vs JDO-それぞれの長所と短所？
私はORMを概念として知っており、数年前に.NETプロジェクトにnHibernateを使用しました。ただし、JavaでORMのトピックに追いついておらず、これらのツールを使用する機会がありません。
しかし、今では、一連のレガシーWebサービスから離れようとして、アプリケーションの1つにいくつかのORMツールを使用する機会があります。
JPA仕様、Hibernateライブラリ自体で得られるもの、JDOが提供するものの違いを伝えるのに苦労しています。
だから、私はこの質問が少しオープンエンドであることを理解していますが、私はいくつかの意見をもらいたいと思っていました：
- それぞれの長所と短所は何ですか？
- 新しいプロジェクトにどちらを提案しますか？
- あるフレームワークと他のフレームワークを使用することが理にかなっている特定の条件はありますか？
いくつかのメモ：
- JDOとJPAは両方とも仕様であり、実装ではありません。
- コードは、標準のJPAのみを使用するように制限する場合、JPA実装を交換できます。 （JDOについても同じです。）
- Hibernateは、JPAのそのような実装の1つとして使用できます。
- ただし、Hibernateは、JPAの機能を超える機能を備えたネイティブAPIを提供します。
IMO、Hibernateをお勧めします。
need Hibernate固有の機能を使用する場合の対処方法について、いくつかのコメント/質問がありました。これを見る方法はたくさんありますが、私のアドバイスは次のとおりです。
ベンダーの提携の見通しに不安がない場合は、Hibernateと、他のJPAおよびJDO実装のどちらかを選択してくださいを含む意思決定におけるベンダー固有のさまざまな拡張。
ベンダーとの提携の見通しに不安があり、ベンダー固有の拡張機能に頼らずにJPAを使用できない場合は、JPAを使用しないでください。 （JDOについても同様）。
実際には、おそらくトレードオフが必要になりますいくらベンダーの抱き合わせが心配ですか？いくらベンダー固有の拡張が必要です。
また、他の要因もあります。たとえば、あなた/スタッフがそれぞれの技術をどれだけよく知っているか、製品のライセンス費用がどれだけかかるか、JDOとJPAの将来についてどう考えているかなどです。
JDOのDataNucleus実装を評価してください。 Hibernateは非常に人気があるように見えたが、すぐに100％透過的な永続化ソリューションではないことに気付いたため、Hibernateから始めました。あまりにも多くの警告があり、ドキュメントには「このような状況がある場合は、このようなコードを書く必要があります」がいっぱいであり、自由にモデリングとコーディングの楽しみを奪いました。 JDOによりneverが原因で、コードまたはモデルを調整して「適切に動作する」ようにしました。 「メモリ内」でのみ使用するかのように単純なPOJOを設計およびコーディングできますが、透過的に永続化できます。
休止状態に対するJDO/DataNucleusのもう1つの利点は、実行時のリフレクションのオーバーヘッドがすべてなく、ビルド時間のバイトコード拡張（大規模プロジェクトのビルド時間に1秒を追加する）を使用するため、メモリ効率が高いことです。休止状態の実行時リフレクションを使用したプロキシパターンよりも。
Hibernateで迷惑になるかもしれない別のことは、あなたが考えているものへの参照がオブジェクトであるということです...それはしばしばオブジェクトの「プロキシ」です。バイトコード拡張の利点がなければ、オンデマンドロードを許可するためにプロキシパターンが必要です（つまり、最上位のオブジェクトをプルするときにオブジェクトグラフ全体をプルすることを避けます）。参照していると思うオブジェクトは多くの場合そのオブジェクトの単なるプロキシであるため、equalsとhashcodeをオーバーライドする準備をしてください。
JDOでは得られないHibernateで得られるフラストレーションの例を次に示します。
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=5
「回避策」へのコーディングが必要な場合は、Hibernateが最適です。モデリング、設計、コーディングにすべての時間を費やし、cleanい回避策に時間を費やさない、クリーンで純粋なオブジェクト指向のモデル駆動型開発を評価する場合は、数時間かけて JDO/DataNucleus を評価します。投資された時間は千倍返済されます。
2017年2月更新
現在、DataNucleusはJDO永続性標準に加えてJPA永続性標準を実装しているため、既存のJPAプロジェクトをHibernateからDataNucleusに移植することは非常に簡単であり、上記のDataNucleusの利点をすべてコードをほとんど変更することなく取得できます、もしあれば。そのため、特定の標準であるJPA（RDBMSのみ）対JDO（RDBMS + SQLなし+ ODBMSes +その他）の選択に関して、DataNucleusは両方をサポートしており、HibernateはJPAのみに制限されています。
Hibernate DB更新のパフォーマンス
ORMを選択する際に考慮すべき別の問題は、ダーティチェックメカニズムの効率です。これは、現在のトランザクションで変更されたオブジェクトを更新するSQLを構築する必要がある場合、特にオブジェクトが多い場合に非常に重要になります。このSOの回答には、Hibernateのダーティチェックメカニズムの詳細な技術的説明があります。 JPAとHIBERNATEの挿入は非常に遅い
私は最近Javaプロジェクトの永続化フレームワークを評価および選択しましたが、私の発見は次のとおりです。
私が見ているのは、JDOを支持するサポートが主に次のとおりであるということです。
- 非SQLデータソース、db4o、hbase、ldap、bigtable、couchdb（cassandraのプラグイン）などを使用できます。
- sQLデータソースから非SQLデータソースへ、またはその逆に簡単に切り替えることができます。
- プロキシオブジェクトがないため、hashcode（）およびequals（）の実装に関する苦痛が少ない
- pOJOが増えるため、必要な回避策が少なくなります
- より多くの関係とフィールドタイプをサポート
JPAのサポートは主に次のとおりです。
- より人気
- jdoは死んだ
- バイトコード拡張を使用しません
JDO/Datanucleusを明らかに使用していないJPA開発者から、JDOを使用しないことに対する弱い議論を提供する多くのpro-JPAの投稿を見ています。
また、JDOに移行したJDOユーザーからの投稿も多く見られ、その結果、より幸せになっています。
JPAがより一般的になっているという点では、これは技術的に優れているというよりも、RDBMSベンダーのサポートによるところが大きいようです。 （私にとってVHS/Betamaxのような音）。
JDOとそのリファレンス実装Datanucleusは、GoogleがGAEに採用し、ソースコード（http://sourceforge.net/projects/datanucleus/）で積極的に開発していることから明らかなように、明らかに死んでいません。
バイトコードの強化によりJDOについて多くの苦情がありますが、なぜそれが悪いのかについての説明はまだありません。
実際、NoSQLソリューションにますます夢中になっている世界では、JDO（およびdatanucleusの実装）のほうがはるかに安全です。
JDO/Datanucleusの使用を開始し、db4oとmysqlの使用を簡単に切り替えられるようにセットアップしました。迅速な開発には、db4oを使用し、DBスキーマについてあまり心配する必要がなく、スキーマがデータベースにデプロイするために安定したら、便利です。後で、アプリケーションのすべて/一部をGAEにデプロイするか、リファクタリングをあまり行わずに分散ストレージ/ map-reduce la hbase/hadoop/cassandraを利用できると確信しています。
Datanucleusを使い始める際の最初のハードルは少し厄介であることがわかりました-datanucleus Webサイトのドキュメントを手に入れるのは少し難しいです-チュートリアルは私が望んでいたほど簡単に理解できません。そうは言っても、最初の学習曲線を超えたら、APIとマッピングに関するより詳細なドキュメントは非常に優れています。
答えは、あなたが望むものに依存します。私はむしろ、よりクリーンなコード、ノーベンダーロックイン、よりポジョ指向、nosqlオプションとより人気のあるものが欲しいです。
他の開発者/羊の大多数と同じことをしているという温かくうるさい感じがしたい場合は、JPA/hibernateを選択してください。分野をリードしたい場合は、JDO/Datanucleusを試してみてください。
新しいプロジェクトにどちらを提案しますか？
どちらもお勧めしません！代わりに、Spring DAOのJdbcTemplateをStoredProcedure、RowMapper、およびRowCallbackHandlerと一緒に使用します。
私自身のHibernateでの経験では、事前に節約された時間は、予想外のカスケード更新動作などの問題を理解してデバッグしようとする無限の日々によって相殺される以上です。
リレーショナルDBを使用している場合、コードがそれに近いほど、より多くの制御が可能になります。 SpringのDAOレイヤーを使用すると、定型コードの必要性を排除しながら、マッピングレイヤーを細かく制御できます。また、Springのトランザクションレイヤーに統合されるため、コードに侵入することなく、複雑なトランザクション動作を（AOPを介して）非常に簡単に追加できます（もちろん、これもHibernateで取得できます）。
JDOは死んだ
JDOは実際には死んでいないので、事実を確認してください。 JDO 2.2は2008年10月にリリースされましたJDO 2.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にはormマッピングがあるため、ベンダーを変更するために1日以内に話しています）。私のように100以上のテーブルがある場合、これは巨大です。さらに、クラスター単位のキャッシュエビクションを備えたビルトインキャッシュを利用できます。 SQL/Jdbcは高性能クエリには適していますが、透過的な永続性はアルゴリズムとデータ入力ルーチンの作成にはるかに優れています。システム全体で約16のSQLクエリしかありません（50k行以上のコード）。
JDOが死んだと言う人は誰でも占星術のFUDモンガーであり、彼らはそれを知っています。
JDOは健在です。この仕様は、はるかに若くて制約のあるJPAよりも強力で、成熟しており、高度です。
JPA標準で利用可能なものだけに制限したい場合は、JPAに書き込み、DataNucleusをJPAの他の実装よりも高性能で透過的な永続化実装として使用できます。もちろん、JDOがもたらすモデリングの柔軟性と効率性が必要な場合、DataNucleusはJDO標準も実装します。
私は自分でこれを調べてきましたが、この2つの間に大きな違いはありません。大きな選択は、どの実装を使用するかだと思います。私自身は DataNucleus プラットフォームを検討しました。これは両方のデータストアに依存しない実装です。
同じプロジェクトでHibernate（JPA実装）とJPOX（JDO実装）を使用しました。 JPOXは問題なく動作しましたが、バグがかなり迅速に発生し、そこでは一部のJava 5言語機能がサポートされていませんでした。 XAトランザクションでNiceを再生する際に問題が発生しました。 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で開発）