Hibernate或JPA或JDBC或？ [英] Hibernate or JPA or JDBC or?

问题描述

我正在开发一个Java桌面应用程序，但在为我的持久层选择一项技术时遇到了一些困惑。

到现在为止，我一直在使用JDBC进行数据库操作。现在，我学习了Hibernate和JPA，但仍然是这些技术的新手。

现在我的问题是Java的使用桌面应用程序？

• JPA




• Hibernate

DAO
>


• 您的任何其他建议...






我知道他们没有最好的选择，它完全取决于项目的复杂性和要求，所以下面是我的项目的要求





1. 这不是一个复杂的应用程序。它仅包含5个表（和5个实体）
   
2. 我不想让代码更灵活，以便以后可以轻松更改数据库


3. 应用程序的大小应尽可能小，因为我必须通过互联网将其分发给我的客户。


4. 它必须可以免费用于商业开发和分发。
>


============================== ====== EDITED =======================================





基于下面的答案，我想使用JPA来防止自己编写供应商特定的SQL代码。



但是我在 Java持久性API 中提到了JPA中的一些问题

解决方案

以下是我的看法： 无需将客户端连接到Hibernate，TopLink等的方式来执行Java持久性。


• Hibernate：如果你有一个映射的对象模型，这是一个不错的选择。


• JDBC：所有的Java持久性都建立在这个基础之上。最低等级


• DAO：比技术更多的模式; CRUD操作接口。
  iBatis：在JDBC（原始SQL）和Hibernate（ORM）之间的一半。


• JDO：Java Data Objects，它是另一个Java持久性规范。 （例如， Apache JDO ）

这不是一个复杂的应用程序。它只包含5个表（和5
实体）

其中任何一个都可以工作，但JDBC将是最简单的。所有其他的都建立在JDBC之上。

我想让代码更灵活，以便稍后可以更改数据库
轻松

架构更改对所有技术都有类似的影响。

应用程序的大小应该尽可能小，因为我将
分配给我的客户
通过互联网。

使用JPA或Hibernate将需要JARs，这会增加部署的规模。 JDBC将最小化这一点。

它必须可以免费用于商业开发和分发。

查看所有技术的许可证。应该不会有任何问题。

供参考：可以编写一个通用的DAO接口：

 包持久化; 
 
 import java.io.Serializable; 
 import java.util.List; 
 
 public interface GenericDao< T，K extends Serializable> 
 {
 T find（K id）; 
列表< T>找（）; 
列表< T>找到（T例子）; 
列表< T> find（String queryName，String [] paramNames，Object [] bindValues）; 
 
 K save（T实例）; 
无效更新（T实例）; 
 void delete（T实例）; 
 
 
 
 $ b $ p 
 $ b 
如果你的对象与你的五张桌子映射1：1，我会说JPA过度平方。
 
 
 
您的应用程序目前的大小是3MB JAR？如果不是，那么Hibernate或JPA的大小将会增加一倍以上。你可以精确量化多少。还有不止一个JAR，因为它们都有依赖关系。  
 
 YAGNI说你应该保持简单。这是五张桌子！  
 
 
更改供应商，如果您的操作正确，则意味着切换JDBC驱动程序JAR，更改驱动程序类名称以及添加新的连接URL  - 您必须执行no不管你选择哪种技术。 
 
 
我发现数据库不会从根本上改变。你会改变模式，但整个供应商？不太可能，特别是如果你有几个客户。制作用户群切换数据库会带来很大的不便。
 
 
 
您计划随附哪一个？ HSQL或者其他需要安装MySQL的东西？这是一个更关注的问题。
 
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 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.

                        
这篇关于Hibernate或JPA或JDBC或？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！