JPAとSpring JdbcTemplate

Question

新しいプロジェクトでは、JPAは常にリレーショナル・データを処理するために推奨されるツールですか、Spring JdbcTemplateを使用するのが良いシナリオがありますか？あなたの応答に考慮すべきいくつかの要因：データ・キャッシング層で

パフォーマンス

を統合することが可能な開発者の専門知識

やすさの既存のスキーマとテーブル

レベル対

• 新しいデータベーススキーマ
• 考慮すべき他の関連要因はありますか？

Answer 1

ドメインモデルを使用してデータベーススキーマにアクセスしない場合は、Spring JdbcTemplateを使用してください。 JdbcTemplateを使用すると、より柔軟な、より低レベルのアクセスを使用していますが、おそらくより定型的なものになります。

Spring JdbcTemplateは、エキゾチックなデータベーススキーマとストアドプロシージャのフォーカスでより簡単に使用できます。 JPAを使用すると、データベース・スキーマがドメイン・モデルに正しくマップされていることを確認する必要があります。

両方のテクノロジには、リレーショナルデータベース、SQLおよびトランザクションを知っている開発者が必要です。 JPAでは、隠された複雑さが増します。

JPAは、オブジェクト指向のフォーカスによってキャッシュエントリの識別、更新、および無効化が容易になるため、データキャッシングレイヤーに簡単に挿入することができます。

JdbcTemplateベースのバックエンドをより細かくチューニングできますが、ほとんどの場合、より多くのコードが含まれています。

JPAではデータベーススキーマのドメインモデルを取得できますが、多くの場合、追加のDTOクラスを使用する必要があります。 JdbcTemplateを使用すると、DTOクラスで直接操作できます。

Answer 2

@Timoに同意します。私が追加/拡張する唯一の他の洞察は、ORMがあなたのデータへの純粋なSQLアクセスとは異なるセマンティクスを持っていることです。

ORMのポイントは、データができるだけDB内にあるという事実を抽象化することです。 ORMを適切に使用すると、すべての永続性操作が1つの（うまくいけば）薄いレイヤーで処理されます。モデルオブジェクトには永続コードがほとんどまたはまったくありません。 ORMを使用しているという事実は、あなたのモデルには見えないはずです。

このため、ORMは、特定の操作（簡単なCRUD操作）のためにあなたの人生を容易にする上で非常に優れています。モデルオブジェクトをロードして提示したり、更新したり、削除したりすることができます。データにアクセスすると、ビジネスロジックを記述できるモデルオブジェクトが戻されるため、作業が楽になります。 JDBCを使用する場合は、オブジェクトインスタンスをデータから「水和（hydrate）」する必要があります。これは、複雑でエラーを起こしやすいものです。

ORMは必ずしも最良の選択ではありません。 JPAは仕事のためのツールです。もしそのツールがその仕事に十分でない場合は、より良いツールを探したいでしょう。たとえば、オブジェクトグラフ全体をコピーしてそれらのオブジェクトの新しいコピーを保存するというシナリオがありました。 ORMを使用した場合（私がやろうとしたように）、すべてのオブジェクトをDBからロードしてからコピーし、新しいオブジェクトを保存する必要がありました。私は長すぎました。

より良い解決策は、単純にjdbcベースの操作と「select via sql」呼び出しを使用して新しい行を作成することでした。それは速かった、コードはより簡単だった。

他に考慮すべきことは、JDBCに慣れていて、締め切りがあるということです.ORMのバンドワゴンに飛び乗る必要はありません。 Spring JdbcTemplateクラスは非常に強力で便利です。場合によっては、仕事のための最良のツールがあなたが知っているものです。あなたはORMに慣れるべきですが、必ずしも高い期待を持っているプロジェクトではないでしょう。学ぶべきことがたくさんありますが、それほど簡単ではありません。実際には、jdbcとormを使用する選択肢の中で、ある複雑さのセットを別のものと交換しています。

Answer 3

私はこの投稿に少し遅れていますが、私はORMよりJdbcTemplateを使用する傾向があります。私はSQLをよく知っており、実際に私のDBから "抽象化"したくない。私はほとんどの時間を見つける、私のアプリケーションは、私はどこにほとんどのビジネスロジックをプッシュするDBビューを使用しています。私は適切にJdbcTemplateの実装を持つDAOを階層化しています。それは "クリーン"であり、ほとんどの定型コードはJdbcTemplateによって隠されています（そして、オンラインドキュメントはORMのものよりもはるかに優れているようです）。限られた時間、私はHibernateのようなものを使っていましたが、うまくいきました。時間が節約できました...しかし、正しく動作していなかったときには、 "WTF"デバッグの日がかかりました。私はJdbcTemplate DAOがデバッグする20分以上を費やす必要はありませんでした。私は、他の人が指摘したように、キーがSQL/Schema Designでどれほど快適であるかと思います。

Answer 4

これは他の回答では言及されていませんが、両方を使用するとうまくいきます。私のアプリケーションでは、JPAとJdbcTemplateを使用していますが、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.entityManager.queryForList("SELECT .. ",SomeProjectPojo.class); 
    } 
} 

春の素晴らしいところは、JPAの例外から春ダオ例外階層に例外翻訳がJPAとjdbcTemplateの両方で動作することです。 JPAが理にかなったらJPAを、理に適ったらjdbcTemplateを使います。

Answer 5

私たちは、より柔軟性があるため、Hibernate JDBCTemplateを使用しています。また、不要なデータをアプリに「ロード」していないため、JPAよりも優れたパフォーマンスを発揮します。
JDBCTemplateのケースでは、SQLスキルは、必要なものを正確な速度で正確に提供するための長い道のりです。