web-dev-qa-db-ja.com

HibernateまたはJPAまたはJDBCまたは?

Javaデスクトップアプリケーションを開発していますが、パーシステンスレイヤーのテクノロジーを選択するときにいくつかの混乱があります。

これまで、DB操作にJDBCを使用してきました。さて、最近私はHibernateとJPAを学びましたが、それでもこれらのテクノロジーの初心者です。

今私の質問は私のJava以下のデスクトップアプリケーションに何を使用するのですか?

  • JPA

  • Hibernate

  • JDBC

  • DAO

  • あなたからの他の提案...

それらからの最良の選択がないことを知っています。それは完全にプロジェクトの複雑さと要求に依存するので、以下は私のプロジェクトの要件です

  1. 複雑なアプリケーションではありません。 5つのテーブル(および5つのエンティティ)のみが含まれています
  2. 後でデータベースを簡単に変更できるように、コードを柔軟にしたくない
  3. アプリケーションのサイズは、インターネット経由でクライアントに配布する必要があるため、可能な限り小さくする必要があります。
  4. 商用開発および配布で自由に使用できる必要があります。

====================================編集済み============= ==========================

以下の回答に基づいて、ベンダー固有のSQLコードを記述できないように、JPAを使用したいと思います。

しかし、JPAでいくつか問題があります Java Persistence API

34
Yatendra Goel

これが私の見解です。

  • JPA:不可知論の方法JavaクライアントをHibernate、TopLinkなどに結合せずに永続化する.
  • Hibernate:オブジェクトモデルをマップする場合に適しています。
  • JDBC:すべてJava永続性はこれに基づいて構築されています。最低レベル
  • DAO:テクノロジーというよりパターンです。 CRUD操作インターフェース。
  • iBatis:JDBC(生のSQL)とHibernate(ORM)の中間。
  • JDO:Javaデータオブジェクト。これは、Java永続性の別の仕様です。例: Apache JDO

複雑なアプリケーションではありません。 5つのテーブル(および5つのエンティティ)のみが含まれています

これらはどれでも機能しますが、JDBCが最も簡単です。他のすべてはJDBCの上に構築されています。

後でデータベースを簡単に変更できるように、コードを柔軟にしたい

スキーマの変更は、すべてのテクノロジーで同様の効果があります。

アプリケーションのサイズは、インターネット経由でクライアントに配布する必要があるため、可能な限り小さくする必要があります。

JPAまたはHibernateを使用するには、デプロイメントのサイズを増やすJARが必要です。 JDBCはこれを最小化します。

商用開発および配布で自由に使用できる必要があります。

すべてのテクノロジーのライセンスをご覧ください。それらのいずれにも問題はないはずです。

参考:一般的なDAOインターフェースを書くことは可能です:

package persistence;

import Java.io.Serializable;
import Java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);
    List<T> find(String queryName, String [] paramNames, Object [] bindValues);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

オブジェクトが5つのテーブルと1対1で対応している場合、JPAは2乗だと言えます。

現在、アプリは3MB JARのオーダーですか?いいえの場合、HibernateまたはJPAはサイズを2倍以上にします。あなたはどれだけ正確に定量化することができます。また、両方に依存関係があるため、複数のJARがあります。

YAGNIは、それをシンプルに保つべきだと言っています。 5つのテーブルです。

ベンダーを適切に変更すると、JDBCドライバーJARを切り替え、ドライバークラス名を変更し、新しい接続URLを追加することになります。これは、どのテクノロジーを選択する場合でも行う必要があります。

データベースはそれを根本的に変えないことがわかりました。スキーマを変更しますが、ベンダー全体ですか?特にクライアントが複数ある場合はそうではありません。ユーザーベースの切り替えデータベースを作成することは大きな不便になります。

どちらを同梱するつもりでしたか? MySQLなどのインストールが必要なHSQLまたは何か?それはより適切な懸念事項です。

54
duffymo

JPAは、オブジェクトリレーションマッピングを使用したい場合に確かに使用できます。これは、実装にとらわれず(Hibernate、Toplinkなどで使用できることを意味します)、事実上の標準です。 Hibernateにはより豊富な機能セットがありますが、これは非標準のソリューションです-しかし多くの人がそれを使用しています...私は個人的に常にHibernateに裏打ちされたJPAを使用しています。私は休止状態の特定のものに近づかないようにしていますが、必要に応じて-それは私のためにあります。

ただし、JPA/Hibernateなどのフレームワークを5つのテーブルに使用することは、少しやり過ぎになる可能性があります。アプリケーションは約5MB大きくなり、より多くのメモリを消費します。 DAOとペアになっているJDBCを使用することを選択するだけです。

JDBCはベンダー(データベース)固有のSQLを使用するため、別のデータベースの使用を計画している場合、これは問題になる可能性があります。 JPAには、この領域で明らかな利点があります。

どちらを選択しても失敗することはありません。サイズとメモリ消費の増加が問題であり、ボイラープレートDAO JDBCコードを作成してもかまいません。私は一般的にこれが嫌いです:-)

9
Bozhidar Batsov

このスケールでは、何でも問題なく機能します。 iBatis も検討してください。

2
lexicore