web-dev-qa-db-ja.com

Java File(つまりJDBCに直接)でSQLクエリを直接記述するのではなく、JPAを使用するのはなぜですか?

私はJPA (Java Persistent API)とは何か、それをサポートしているベンダー(DataNucleus、JBoss Hibernateなど)をいくつかの記事で読んでいます。

ORM(オブジェクトリレーショナルマッピング)の経験がありません。

これまでに行ったことは、DTOとDAOを使用して独自のデータベースクラスを作成することです。これまでのところ、私が持っているものに満足していますが、知りたいですなぜ人々はJavaファイルでJPAを使用するのですか?.

私にとって、DAOクラスを書くことは、以下のようなものでよいと思います。

public class DAOUsers {
     public void insertNewUser(DTO DtoUser) {
           String query = "INSERT INTO users(username, address) " +
                          "VALUES(DtoUser.username , DtoUser.address)";
           Executor.run(query);
     }

}

JPAはJPQLを使用することを学びました。Java永続クエリ言語であり、dbテーブルで直接ではなく、エンティティオブジェクトに対して動作します。

私の理解(Imが間違っていれば私を修正)は、ここでのエンティティオブジェクトは私のDTOオブジェクトと同じです(Beanのような?)

しかし、とにかく..ファイルに純粋なSQLを書くことよりも、JPAが本当に恩恵をもたらすものは何ですか? JPAが必要とする注釈を使用し、SQLを読み取り不能にしたように思えますが、私にとってはあまり魅力的ではありません。

さらに説明が必要な場合はお知らせください。このトピックは初めてなので、意見をお聞かせください。

47
masato-san

Java File(つまりJDBCに直接)でSQLクエリを直接記述するのではなく、JPAを使用するのはなぜですか?

特定のプロジェクトでは、エンジニアがデータストアへのアクセスに使用される実際のSQLクエリではなく、オブジェクトモデルにもっと集中する必要があります。質問は実際には次のように解釈できます

ORMフレームワークを使用する必要があるのはなぜですか?

異なるコンテキストで異なる答えを持つことができます。

ほとんどのプロジェクトでは、持続性が2番目の懸念事項であるドメインモデルを使用することでメリットが得られます。 JPA(実装)または他のほとんどのORMフレームワークを使用すると、すべてのエンティティ、つまりデータベース内のテーブルをJavaのクラスとしてモデル化することができます。さらに、これらのクラスに動作を埋め込むことも可能であり、したがって、動作が豊富なドメインモデルを実現できます。このモデルのエンティティには、複数の層にデータを転送するためのDTOを置き換える目的など、複数の目的があります。

そうは言っても、特にデータモデルが既に確立されている場合、またはデータベーステーブルをJavaまた、特定の場合、ORMフレームワークによって生成されたSQLを完全に調整する必要がある場合、ORMフレームワークは通常不適切です。

関連する質問

  1. Java EEアーキテクチャ-JPA 2のようなORMを使用する場合、DAOは引き続き推奨されますか?
  2. ORMまたはプレーンSQLを使用しますか?
  3. ORM vs Handcoded Data Access Layer
40
Vineet Reynolds

ファイルに純粋なSQLを書くことよりも、JPAが本当に恩恵を受けるのは何ですか?

利点の一部を次に示します。

  • JPAを使用すると、データベース固有のSQL方言でDDLを記述する必要がなくなります。代わりに、XMLで「マッピング」を記述するか、Javaアノテーションを使用します。

  • JPAを使用すると、SQLのデータベース固有の方言でDMLを記述することを回避できます。

  • JPAを使用すると、DML言語をまったく使用せずにJavaオブジェクトとグラフをロードおよび保存できます。

  • doクエリを実行する必要がある場合JPQLでは、(ネイティブ)SQLテーブルと列ではなく、Javaエンティティ)でクエリを表現できます。

一般的に言えば、JPAはJDBC + SQL +手書きのマッピングよりもシンプルで、クリーンで、労働集約的ではありません。データモデルが複雑であればあるほど、有益になります。

ただし、パフォーマンスがオーバーライドの懸念事項である場合、JPAはアプリケーションとデータベースの間にレイヤーを追加することで邪魔する傾向があります。アプリケーションでパフォーマンスを最大化するためにネイティブデータベースクエリとスキーマを広範囲に手動で最適化する必要がある場合、JPAはおそらく適切ではありません。

はるかに快適同じアプリケーションでJava、JDBC、およびSQLをジャグリングする場合は、ORMで厄介な詳細を処理するよりも、JPAもおそらく適していません。 (しかし、あなたがそうであれば、あなたはおそらく少数派です...)

23
Stephen C

これは古い質問ですが、新しい答えに値すると思います。私はJPAの遅い導入者であり、数年にわたってそれをオン/オフで使用しており、新しいアプリケーションを立ち上げることのシンプルさに感銘を受けた瞬間がありましたが、私は明らかに感銘を受けませんでしたJPAを正しく実行するために必要なパフォーマンス、複雑さ、学習曲線を備えています。このスレッドの答えは、実際に私の立場を補強します。

最初に、@ vineetは「エンティティには複数の目的がある」ことを提案します...これは実稼働で見たことがあり、ORMによって推奨されていると思います。結束と単一の責任プリンシパルはこれで終わりです。私の経験では、データベースエンティティにビヘイビアを追加することは問題を求めています。私はこれをやったので、後悔するために生きていたので、私はこれを知っています。

第二に、ORAが解決しようとするミスマッチ(不成功)に起因するすべての重さ(およびパフォーマンスの問題)なしにRDBMSでクラスを使用する機能を提供する、JPAの複雑さに対する単純な代替手段があります。 1,000を超えるテーブルを持つアプリケーションで10年にわたって非JPAリレーショナルクラスマッピングツールを使用してきましたが、データベースへの直接アクセスよりもJPAがどのように改善されているかわかりません。 JPAは、クラスモデルにオーバーヘッド(アノテーションとJQLの形式)を追加している間、データベースの能力を覆い隠します...それは他の方法で動作するべきではありませんか?

@waterは、理論上は真実であるが、実際には実用的ではない多くのことを示唆しています。たとえば、バックエンドデータベースを3回切り替えたので、いくつかの構成の微調整などがなくても完了していることを読者に保証できます。永続化レイヤーの維持に多くの時間を費やしている場合、データベースモデルは進化しており、JPAで同じまたはそれ以上の作業を行うことをお勧めします。特に、JPAで自明ではないクエリでJQLを使用する必要がある場合!

ほとんどすべての人が、JPA開発者がSQLを知る必要がないと偽装しています。実際に見てきたことは、SQL and JQLを学ぶ必要があるということです。どうやらDDLを実行する必要はないようですが、些細でないアプリケーションではもちろん DDLを知る必要があります。 Hibernateは自動DDL生成の使用を推奨していません。どうやら、ネイティブクエリを呼び出す場合を除き、DMLを実行する必要はないようです。ネイティブクエリは、もちろん移植性がなく、キャッシュを破壊し、JDBCと同じ問題を抱えています。

最終的に、ドメインモデルがビジネスロジックから独立している適切に構造化されたアプリケーションでは、JPAは非常に高度な学習曲線であることがわかった機能に対してほとんど機能を提供しません。 。私はJDBCを直接使用しませんが、Apache DBUtilsのようなものは行をオブジェクトにマップするJDBCの上にシンプルなレイヤーを提供し、少しの努力でJPAの利点のほとんどを隠蔽もオーバーヘッドもなしに提供できます。

JDBC 1.0以降、さまざまなライブラリ(およびJDBCの前のiODBCとESQL)を使用して、Javaデータベースアプリケーションを開発してきました。パフォーマンス上の理由だけで、JPAは完了しました。パフォーマンスがよければ、学習曲線と不完全な抽象化によって深刻な一時停止が生じます。JPAは複雑で、開発者が実際に気にする必要のある詳細を隠そうとします。 JPAはその性質上、この種のエラーを簡単にします。

私はJDBCを支持しているのではなく、単にJPAに反対しているだけです。 SQLを使用しない、または使用できない開発者は、おそらくリレーショナルアプリケーションを作成しないでください。私のような命を救うために行列代数を実行できなかった私のような開発者は、3Dゲームを作成する必要があります。生活にSQLを使用する開発者は、そもそも必要のないラウンドトリップを回避するために、サーバーに休止状態で送信する歪んだSQLに恐怖を感じる必要があります。

14
Doctor Eval

正しく行われた場合、SQLクエリをJava hibernateなどのJPA実装を持つオブジェクトに直接マッピングできます。最近、POJOと3つまたは4つのアノテーションと少しのセットアップコードを使用したプロジェクトを行いました。ストアドプロシージャを取得し、それを(POJOクラスタイプの)オブジェクトのリストに直接マッピングするこれは私にとってJPAの力の一部です。

SQL + JDBCをまっすぐに使用するように使用している場合、利点はわかりません。

JPAの利点に関する適切な記事 こちら があります。

お役に立てれば。

6
javamonkey79

オブジェクトは私たちの生活の中で最も重要なものの1つであり、オブジェクトをプログラミングすることは問題を単純化するための非常に簡単な方法であることがわかっているため...事はオブジェクトを意味します...

  • エンタープライズアプリケーションでSQLステートメントを手動でコーディングしている場合、開発レイヤーの永続化レイヤーの更新と保守にかなりの時間を費やしています。

永続化では、==>結果セットまたはデータ処理にJDBC APIが不要になります。 ==>コードの行数を減らすのに役立ち、&&&&&&& ==>基になるSQLデータベースとSQLダイアレクトからアプリケーションを抽象化します。他のSQLデータベースに切り替えても、Hibernate構成ファイルの変更はほとんど必要ありません(1回書き込み/どこでも実行)。

6
Ravi Parmar

さらに、ご存知のように、Javaのスローガン:「一度書くだけで、どこでも実行できます」

また、JPQLを使用すると、すべてのデータベース(DB2、Oracleなど)でJPQLクエリを実行できます。

0
yetAnotherSE
  • JPAは、パフォーマンスを重視しない複雑なアプリケーションに最適です。
  • JDBCは、パフォーマンスが重要なパフォーマンスを発揮する場合に最適です。
0
Shreyu