# Hibernate or JPA or JDBC or?

 1 I am developing a Java Desktop Application but have some confusions in choosing a technology for my persistence layer. Till now, I have been using JDBC for DB operations. Now, Recently I learnt Hibernate and JPA but still I am a novice on these technologies. Now my question is What to use for my Java Desktop Application from the following? JPA Hibernate JDBC DAO any other suggestion from you... I know that there is no best choice from them and it totally depends on the complexity and the requeirements of the project so below are the requirements of my project It's not a complex application. It contains only 5 tables (and 5 entities)I wan't to make my code flexible so that I can change the database later easilyThe size of the application should remain as small as possible as I will have to distribute it to my clients through internet.It must be free to use in commercial development and distribution. ==================================== EDITED ======================================= On the basis of the below answers, I would like to go with JPA so as to prevent myself from writing vendor-specific SQL code. But I have some problems in JPA which are mentioned at http://stackoverflow.com/questions/2560125/java-persistence-api

Here's my take:

• JPA: Agnostic way to do Java persistence without coupling your clients to Hibernate, TopLink, etc.
• Hibernate: Good choice if you have an object model to map to.
• JDBC: All Java persistence is built on this. Lowest level
• DAO: More of a pattern than a technology; CRUD operation interface.
• iBatis: Halfway between JDBC (raw SQL) and Hibernate (ORM).
• JDO: Java Data Objects, which is another specification for Java persistence. (e.g., Apache JDO)

It's not a complex application. It contains only 5 tables (and 5 entities)

Any of these will work, but JDBC will be the simplest. All the others are built on top of JDBC.

I want to make my code flexible so that I can change the database later easily

Schema changes will have similar effects in all technologies.

The size of the application should remain as small as possible as I will have to distribute it to my clients through internet.

Using JPA or Hibernate will require JARs that will add to the size of your deployment. JDBC will minimize this.

It must be free to use in commercial development and distribution.

See licenses of all technologies. Shouldn't be a problem with any of them.

FYI: It's possible to write a generic DAO interface:

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);
}


If your objects map 1:1 with your five tables, I'd say that JPA is overkill squared.

Is your app currently on the order of 3MB JAR? If no, then Hibernate or JPA will more than double the size. You can quantify exactly how much. And there's more than one JAR, because they both have dependencies.

YAGNI says that you should keep it simple. It's five tables!

Changing vendor, if you do it properly, means switching a JDBC driver JAR, changing the driver class name, and adding the new connection URL - which you have to do no matter what technology you pick.

I find that databases don't change that radically. You'll change the schema, but the entire vendor? Not likely, especially if you have several clients. It'll be a major inconvenience to make a user base switch databases.

Which one were you planning to ship with? HSQL or something that will require an installation like MySQL? That's a more pertinent concern.

JPA is certainly to way to go is you want to use object relation mapping - it's implementation agnostic(meaning you can use it with Hibernate, Toplink, etc) and it's the de facto standard. Hibernate has a richer feature set, but this is a non-standard solution - many people use it though... I personally always use JPA backed by Hibernate. I try to stay away from the hibernate specific stuff, but if need it - it's there for me.

Using a framework such as JPA/Hibernate for 5 tables can be a bit of a overkill though. Your application will be around 5MB bigger and will consume a litter more memory. You may simply opt to use JDBC paired with DAO.

Since JDBC uses SQL which is vendor(database) specific this might be problematic is you're planning on using different databases. JPA has a clear advantage in this area.

Whatever you choose you cannot go wrong - you need to ask yourself mostly is the increased size and memory consumption an issue and are you willing to write boilerplate DAO JDBC code. I generally hate this :-)

• 本文已收录于以下专栏：

## PL_SQL_Oracle_Or_Jdbc.pdf

• 2011年03月23日 10:04
• 523KB
• 下载

## 【最新】spring mvc mybatis or hibernate bootstrap HTML5 框架

• 2015年08月02日 11:53
• 2.77MB
• 下载

## java项目案例 java项目源码 java后台框架源码 企业级 SpringMVC mybatis or hibernate

﻿﻿ 获取【下载地址】   QQ: 313596790   【免费支持更新】 A 代码生成器(开发利器);全部是源码      增删改查的处理类，service层，mybatis的xml，S...

## Hibernate or Mybatis

Hibernate or Mybatis
• wwq518
• 2016年05月14日 15:37
• 238

## Could not open Hibernate Session for transaction . or java.net.SocketException: Broken pipe

Could not open Hibernate Session for transaction   最近做一个项目,布暑后出现"Could not open Hibernate Session...

## hibernate级联保存问题，出错not-null property references a null or transient value

Servlet.service() for servlet default threw exception org.hibernate.PropertyValueException: not-nul...

举报原因： 您举报文章：Hibernate or JPA or JDBC or? 色情 政治 抄袭 广告 招聘 骂人 其他 (最多只允许输入30个字)