新しいプロジェクトの場合、JPA は常にリレーショナル データを処理するための推奨ツールですか、それとも Spring JdbcTemplate がより良い選択であるシナリオはありますか? 回答で考慮すべきいくつかの要素:
- 新しいデータベース スキーマと既存のスキーマおよびテーブル
- 開発者の専門知識のレベル
- データ キャッシング レイヤとの統合が容易
- パフォーマンス
- 考慮すべきその他の関連要因はありますか?
新しいプロジェクトの場合、JPA は常にリレーショナル データを処理するための推奨ツールですか、それとも Spring JdbcTemplate がより良い選択であるシナリオはありますか? 回答で考慮すべきいくつかの要素:
ドメイン モデルを介してデータベース スキーマにアクセスしたくない場合は、Spring JdbcTemplate を使用します。JdbcTemplate を使用すると、柔軟性が向上しますが、定型句も増える可能性があります。
Spring JdbcTemplate は、エキゾチックなデータベース スキーマとストアド プロシージャ フォーカスでより簡単に使用できます。JPA を使用して、データベース スキーマがドメイン モデルに正しくマップされていることを確認する必要があります。
どちらのテクノロジでも、開発者はリレーショナル データベース、SQL、およびトランザクションに精通している必要があります。ただし、JPA を使用すると、隠れた複雑さが増します。
私の知る限り、JPA はデータ キャッシング レイヤーにより簡単にプラグインできます。これは、オブジェクト指向のフォーカスにより、キャッシュ エントリの識別、更新、および無効化が容易になるためです。
JdbcTemplate ベースのバックエンドをより適切に調整できますが、ほとんどの場合、より多くのコードが必要になります。
JPA を使用すると、データベース スキーマのドメイン モデルを取得できますが、多くの場合、追加の DTO クラスを使用する必要があります。JdbcTemplate を使用すると、DTO クラスを直接操作できます。
この投稿には少し遅れましたが、ORM よりも JdbcTemplate を使用する傾向があります。私はSQLを(かなりよく)知っていますが、DBから「抽象化」されたくありません。ほとんどの場合、私のアプリはほとんどのビジネス ロジックをプッシュする DB ビューを使用しています。JdbcTemplate 実装を持つ DAO を適切に階層化しました。それは「きれい」に感じられ、ほとんどの定型コードは JdbcTemplate によって隠されています (そして、オンラインドキュメントは ORM のものよりもはるかに優れているようです)。Hibernate のようなものを使用した限られた時間は、それが機能したときに時間を節約できることがわかりました...しかし、正しく機能していないときは、「WTF」デバッグに何日もかかりました。JdbcTemplate DAO impl のデバッグに 20 分以上費やす必要はありませんでした。他の人が指摘したように、重要なのは、SQL / スキーマ設計にどれだけ慣れているかだと思います
@ティモに同意します。私が追加/拡張する唯一の他の洞察は、ORMがデータへの純粋なSQLアクセスとは異なるセマンティクスを持っているということです。
ORM のポイントは、データが DB にあるという事実を可能な限り抽象化することです。ORM を適切に使用すると、すべての永続化操作が 1 つの (できれば) 薄いレイヤーで処理されます。モデル オブジェクトには永続化コードがほとんどまたはまったくありません。ORM を使用しているという事実は、モデルから見えないようにする必要があります。
このため、ORM は、特定のタイプの操作、つまり単純な CRUD 操作を簡単にするのに非常に優れています。モデル オブジェクトの読み込み、表示、更新、削除を非常に簡単に行うことができます。データにアクセスすると、ビジネス ロジックを記述できるモデル オブジェクトが返されるため、作業が楽になります。JDBC を使用する場合、データからオブジェクト インスタンスを「ハイドレート」する必要がありますが、これは複雑でエラーが発生しやすい可能性があります。
ORM が常に最良の選択であるとは限りません。JPA は仕事のためのツールです。ツールが仕事に十分でない場合は、より良いツールを見つけたいと思うでしょう。たとえば、オブジェクト グラフ全体をコピーし、それらのオブジェクトの新しいコピーを保存する必要があるシナリオがありました。ORM を使用していた場合 (私が試みたように)、DB からすべてのオブジェクトをロードし、それらをコピーしてから、新しいオブジェクトを保存する必要がありました。時間がかかりすぎました。
より良い解決策は、単純に jdbc ベースの操作と「insert via select」SQL 呼び出しを使用して新しい行を作成することでした。それは速く、コードはより単純でした。
考慮すべきもう 1 つのことは、JDBC に慣れていることと、締め切りがあることです。ORM の時流に乗る必要はありません。Spring JdbcTemplate クラスは非常に強力で便利です。仕事に最適なツールは、あなたが知っているツールである場合があります。ORM に慣れる必要がありますが、期待の高いプロジェクトでは必ずしもそうではありません。学ぶべきことはたくさんあり、それは些細なことではありません。実際には、jdbc と orm のどちらを使用するかを選択する際に、一連の複雑さを別の複雑さと交換しています。
他の回答では言及されていませんが、両方を使用しても問題ありません。私のアプリでは、JPA と JdbcTemplate を使用します。crud タイプの操作には JPA を使用しますが、レポートや簡単な場合は jdbcTemplate を使用します。
@Repository
public class FooRepository
{
@PersistenceContext
private EntityManager entityManager;
@Autowired(required = true)
private JdbcTemplate jdbcTemplate;
public void saveFoo(Foo foo)
{
this.entityManager.persist(foo);
}
public List<SomeReportPojo> getSomeReport()
{
return this.jdbcTemplate.queryForList("SELECT .. ",SomeProjectPojo.class);
}
}
Spring の優れた点は、JPA 例外から Spring Dao 例外階層への例外変換が JPA と jdbcTemplate の両方で機能することです。したがって、意味がある場合は JPA を使用し、意味がある場合は jdbcTemplate を使用します。
仕事では、柔軟性が高いため、Hibernate JDBCTemplate を使用します。また、多くの不要なデータをアプリに「ロード」しないため、JPA よりもパフォーマンスが優れています。
JDBCTemplate の場合、必要なものを適切な速度で正確に提供するには、SQL のスキルが大いに役立ちます。