どのJava ORMを好みますか、またその理由は何ですか？[閉まっている]

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

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

ORMの使用をやめました。

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

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

なし。ORMを使用すると、あまりにも多くの制御が奪われ、小さなメリットしか得られないためです。ORMの使用に起因する異常をデバッグする必要がある場合、得られた時間の節約は簡単に打ち消されます。さらに、ORMは、開発者がSQLを学び、リレーショナルデータベースがどのように機能するか、そしてこれを利益のために使用することを阻止します。

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

• SQLは良いことです。SQLでは、多くのことがかなりうまく表現できます。SQLを完全に抽象化する必要はありません。
• リレーショナルデータモデルは良いことです。過去40年間で最高のデータモデルを証明しました。XMLデータベースや真にオブジェクト指向のデータモデルは必要ありません。代わりに、会社はOracle、MySQL、MSSQL、DB2またはその他のRDBMSのいくつかのインスタンスを実行しています。
• SQLには構造と構文があります。JDBCでは「低レベル」の文字列連結、HQLでは「高レベル」の文字列連結を使用して表現しないでください。どちらも構文エラーを保持する傾向があります。
• 主要なクエリを処理する場合、変数バインディングは非常に複雑になる傾向があります。それは抽象化されるべきものです。
• POJOは、データベースデータを操作するJavaコードを作成する場合に最適です。
• 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))))));

それは基本的にJavaのデファクトスタンダードであり、JPAの作成における原動力の1つだったためです。Springでは優れたサポートが提供されており、ほとんどすべてのJavaフレームワークでサポートされています。最後に、GORMは、Groovyを使用して動的ファインダーなどを実行する、非常に優れたラッパーです。

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

休止状態。

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

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

• システム内のオブジェクトを操作します（システムが適切に設計されている場合）。JDBCを使用している場合でも、データをオブジェクトに転送できるように、最終的に変換レイヤーを作成することになります。しかし私の考えでは、Hibernateはカスタムメイドのソリューションよりも翻訳に優れています。
• それはあなたの支配を奪うものではありません。APIにリモート機能がない場合は、非常に細かい部分で制御できます。ネイティブクエリを実行すれば、それを利用できます。
• 中規模またはそれ以上のシステムでは、保守性を目的とする場合、1トンのクエリ（1か所に分散しているか、分散しているか）を使用する余裕はありません。
• パフォーマンスが重要でない場合。Hibernateはパフォーマンスのオーバーヘッドを追加しますが、無視できない場合もあります。

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

中規模の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();

SimpleORMは、単純明快でマジックがありません。Javaコードですべてのメタデータ構造を定義し、非常に柔軟です。

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

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

Eclipse Linkは、多くの理由からですが、他のメインストリームソリューションよりも膨らみが少ないように感じます（少なくとも面倒な膨らみは少なくなっています）。

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

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

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