Hibernate or JPA or JDBC or?
来源:互联网 发布:人工智能的发展方向 编辑:程序博客网 时间:2024/05/16 12:25
Hibernate or JPA or JDBC or?
4down vote favorite
1
share [g+]share [fb] share [tw]
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 easily
- The 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 :-)
- Hibernate or JPA or JDBC or?
- jdbc or hibernate(jpa)
- Hibernate or JPA Annotation中BLOB、CLOB注解写法
- Hibernate & Proxool or C3p0
- hibernate的or查询
- Hibernate or 的用法
- Hibernate or Mybatis
- Hibernate Tool: hbm2java or hbm2ddl
- Hibernate Tool: hbm2java or hbm2ddl
- hibernate数据类型与OR映射
- hibernate数据类型与OR映射
- hibernate数据类型与OR映射
- hibernate数据类型与OR映射
- hibernate数据类型与OR映射
- hibernate-criteria的or()用法
- 05-hibernate实战,OR映射
- hibernate深入浅出-OR映射(1)
- 'or'='or'
- POJ 3233 等比矩阵的前N项和
- 网络通信时字节序转换原理与网络字节序、大端和小端模式
- 超级POM
- rtsp头字段选项
- IE6判断
- Hibernate or JPA or JDBC or?
- winfrom DataGrideView导出数据到execl和wrod中
- operator=返回对象和引用的区别
- 分享通用基类库-转载微软的数据操作类SQLHELP
- 系统保存客户操作历史记录
- c# socket流转对象
- 国内代理软件CCproxy软件使用方法(图解)
- 利用隐藏参数_asm_allow_only_raw_disks创建ASM环境
- Oracle基础学习笔记(三)(Import, Export, SQL Loader)