web-dev-qa-db-ja.com

どのJava ORMを好みますか、またその理由は何ですか？

これはかなり自由な質問です。新しいプロジェクトを開始し、データベースアクセスと統合するためのさまざまなORMを検討しています。

お気に入りはありますか？近づかないようアドバイスすることはありますか？

javaorm
247
Mike

ORMの使用を停止しました。

その理由は、コンセプトの大きな欠陥ではありません。 Hibernateはうまく機能します。代わりに、クエリのオーバーヘッドが低く、多くの複雑なロジックを大きなSQLクエリに適合させ、処理の多くをデータベースにシフトできることがわかりました。

したがって、JDBCパッケージの使用のみを検討してください。

227
David Crawshaw

なし。ORMを使用すると、わずかなメリットで制御が奪われてしまうためです。 ORMの使用に起因する異常をデバッグする必要がある場合、得られる時間の節約は簡単に吹き飛ばされます。さらに、ORMは、開発者がSQLを学習したり、リレーショナルデータベースがどのように機能するか、またこれを自分の利益のために使用することを推奨しません。

95
simon

多くのORMは優れているため、JDBCの上に抽象化を追加する理由を知る必要があります。 http://www.jooq.org をお勧めします（免責事項：私はjOOQの作成者なので、この答えは偏っています）。 jOOQは次のパラダイムを採用しています。

  • SQLは良いことです。 SQLでは多くのことを非常にうまく表現できます。 SQLを完全に抽象化する必要はありません。
  • リレーショナルデータモデルは良いことです。過去40年間で最高のデータモデルを証明しています。 XMLデータベースや真のオブジェクト指向データモデルは必要ありません。代わりに、会社はOracle、MySQL、MSSQL、DB2またはその他のRDBMSの複数のインスタンスを実行しています。
  • SQLには構造と構文があります。 JDBCの「低レベル」文字列連結、またはHQLの「高レベル」文字列連結を使用して表現することはできません。どちらも構文エラーを保持する傾向があります。
  • 主要なクエリを処理する場合、変数バインディングは非常に複雑になる傾向があります。それは抽象化されるべきものです。
  • データベースデータを操作するJavaコードを記述する場合、POJOは素晴らしいです。
  • POJOは、手作業で記述して保守するのが面倒です。コード生成が進むべき道です。データ型の安全性を含む、コンパイルに対して安全なクエリがあります。
  • データベースが最初に来ます。データベースの上にあるアプリケーションは時間とともに変化する可能性がありますが、データベース自体はおそらく長持ちするでしょう。
  • はい、レガシーデータベースにストアドプロシージャとユーザー定義型（UDT）があります。あなたのデータベースツールはそれをサポートするはずです。

他にも多くの優れたORMがあります。特に、HibernateまたはiBATISには素晴らしいコミュニティがあります。しかし、直感的でシンプルなものを探しているなら、jOOQを試してみてください。気に入ると思います！ :-)

このSQLの例をご覧ください。

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

そして、jOOQでどのように表現できるか：

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));
85
Lukas Eder

Hibernateは、基本的にJavaの事実上の標準であり、JPAの作成の原動力の1つであったためです。 Springでは優れたサポートがあり、ほぼすべてのJavaフレームワークがサポートしています。最後に、GORMは、Groovyを使用して動的ファインダなどを実行するための非常にクールなラッパーです。

.NET（NHibernate）に移植されているため、そこでも使用できます。

57
Abdullah Jibaly

Hibernate、それは：

  • 安定しています-長年にわたって存在しているため、大きな問題はありません
  • oRM分野の標準を規定する
  • 口述に加えて、標準（JPA）を実装します。
  • インターネット上でそれに関する多くの情報を持っています。多くのチュートリアル、一般的な問題解決などがあります
  • 強力です-非常に複雑なオブジェクトモデルをリレーショナルモデルに変換できます。
  • 主要および中規模のRDBMSをサポートしています
  • 簡単に操作できます一度よく学習すれば

ORMを使用する理由（および時期）に関するいくつかのポイント：

  • システム内のオブジェクトを操作します（システムが適切に設計されている場合）。 JDBCを使用している場合でも、データをオブジェクトに転送するために、何らかの翻訳レイヤーを作成することになります。しかし、私の考えでは、Hibernateはカスタムメイドのソリューションよりも翻訳が優れています。
  • 制御を奪うことはありません。物事を非常に詳細に制御できます。APIにリモート機能がない場合は、ネイティブクエリを実行してそれを取得します。
  • 中規模または大規模のシステムでは、1トンのクエリ（1か所に散在している場合もあれば、分散している場合もある）を維持することはできません。
  • パフォーマンスが重要でない場合。 Hibernateはパフォーマンスのオーバーヘッドを追加しますが、無視できない場合があります。
51
Bozho

MyBatis を使用することをお勧めします。 JDBCの上にある薄いレイヤーであり、オブジェクトをテーブルにマップし、プレーンSQLを使用するのは非常に簡単です。すべてを制御できます。

25
adrian.tarau

中規模のJavaSEアプリケーションを書いているときに Avaje Ebean を使って本当に良い経験をしました。

標準のJPAアノテーションを使用してエンティティを定義しますが、はるかに単純なAPIを公開します（EntityManagerまたはそのアタッチ/デタッチされたエンティティは不要です）。また、必要に応じて、SQLクエリまたはイベントプレーンJDBCコールを簡単に使用できます。

また、クエリ用の非常に優れた流動的でタイプセーフなAPIもあります。次のように書くことができます：

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();
18
IgKh

SimpleORM 。これは単純で魔法がないためです。 Javaコードですべてのメタデータ構造を定義し、非常に柔軟です。

SimpleORMは、リレーショナルデータベースのデータをメモリ内のJavaオブジェクトにマッピングすることにより、Hibernateと同様の機能を提供します。クエリはJavaオブジェクトの観点から指定でき、オブジェクトIDはデータベースキーに合わせられ、オブジェクト間の関係は維持され、変更されたオブジェクトは楽観的ロックでデータベースに自動的にフラッシュされます。

ただし、Hibernateとは異なり、SimpleORMは非常に単純なオブジェクト構造とアーキテクチャを使用して、複雑な解析、バイトコード処理などの必要性を回避します。依存関係（Slf4j）。 （Hibernateは2400Kを超え、さらに約2000Kの依存瓶があります。）これにより、SimpleORMの理解が容易になり、技術的なリスクが大幅に削減されます。

11
David Schmitt

Eclipse Link 、多くの理由がありますが、他のメインストリームソリューションよりも肥大化が少ないように感じます（少なくとも、面倒な膨張は少ない）。

ああ、Eclipse LinkがJPA 2.0のリファレンス実装として選ばれました

10
Tom Neyland

自由形式のSQLクエリのJava置換に関する懸念を共有していますが、ORMを批判している人々は、一般にアプリケーション設計が貧弱であるため、そうしていると思います。

真のOODはクラスと関係によって駆動され、ORMはさまざまな関係タイプとオブジェクトの一貫したマッピングを提供します。 ORMツールを使用し、ORMフレームワークがサポートするクエリ言語（Java式ツリー、クエリメソッド、OQLなどを含むがこれらに限定されない）でクエリ式をコーディングすると、間違いなく何かをすることになります。間違っています。つまり、クラスモデルが本来の方法で要件をサポートしていない可能性が高いです。クリーンなアプリケーション設計では、アプリケーションレベルでクエリを実際に必要としません。私は、コードにSQL文字列定数を埋め込むのと同じ方法でORMフレームワークを使用して始めた多くのプロジェクトをリファクタリングしてきましたが、最終的には、一致するとアプリケーション全体がどれだけシンプルで保守可能になるかについて、誰もが驚きました使用モデルでクラスモデルをセットアップします。確かに、検索機能などのようなものにはクエリ言語が必要ですが、クエリは非常に制約されているため、さらに複雑なVIEWを作成し、読み取り専用の永続クラスにマッピングすることで、式を作成するよりも保守と表示がはるかに優れていますアプリケーションのコードの一部のクエリ言語で。 VIEWアプローチはデータベース機能も活用し、具体化により、Javaソース内の手書きSQLよりもパフォーマンス面ではるかに優れたものになります。したがって、重要なアプリケーションがORMを使用しない理由はわかりません。

4
Mirko Klemm