Java Hibernate 或 JPA 或 JDBC 或？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2560500/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Hibernate or JPA or JDBC or?
提问by Yatendra Goel
I am developing a Java Desktop Application but have some confusions in choosing a technology for my persistence layer.
我正在开发一个 Java 桌面应用程序，但在为我的持久层选择技术时有一些困惑。
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.
到目前为止，我一直在使用 JDBC 进行 DB 操作。现在，最近我学习了 Hibernate 和 JPA，但我仍然是这些技术的新手。
Now my question is What to use for my Java Desktop Application from the following?
现在我的问题是以下内容用于我的 Java 桌面应用程序什么？
JPA
Hibernate
JDBC
DAO
any other suggestion from you...
日本特许经营协会
休眠
JDBC
道
你的任何其他建议...
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.
- 这不是一个复杂的应用程序。它只包含 5 个表（和 5 个实体）
- 我不想让我的代码灵活，以便我以后可以轻松地更改数据库
- 应用程序的大小应尽可能小，因为我必须通过互联网将其分发给我的客户。
- 它必须可以免费用于商业开发和分发。
==================================== 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.
基于以下答案，我想使用 JPA 以防止自己编写特定于供应商的 SQL 代码。
But I have some problems in JPA which are mentioned at Java Persistence API
但是我在 JPA 中有一些问题，这些问题在Java Persistence API中提到
回答by lexicore
回答by duffymo
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)
- JPA：在不将客户端耦合到 Hibernate、TopLink 等的情况下进行 Java 持久化的不可知方式。
- Hibernate：如果您有要映射到的对象模型，则是不错的选择。
- JDBC：所有 Java 持久性都建立在此之上。最低级别
- DAO：与其说是一种技术，不如说是一种模式；CRUD 操作界面。
- iBatis：介于 JDBC（原始 SQL）和 Hibernate（ORM）之间。
- JDO：Java Data Objects，Java 持久化的另一种规范。（例如，Apache JDO）
It's not a complex application. It contains only 5 tables (and 5 entities)
这不是一个复杂的应用程序。它只包含 5 个表（和 5 个实体）
Any of these will work, but JDBC will be the simplest. All the others are built on top of JDBC.
其中任何一个都可以使用，但 JDBC 将是最简单的。所有其他的都建立在 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.
使用 JPA 或 Hibernate 将需要 JAR，这会增加您的部署规模。JDBC 将最大限度地减少这种情况。
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:
仅供参考：可以编写一个通用的 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);
}
If your objects map 1:1 with your five tables, I'd say that JPA is overkill squared.
如果您的对象与您的五个表 1:1 映射，我会说 JPA 是矫枉过正的平方。
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.
您的应用程序当前是否为 3MB JAR？如果不是，则 Hibernate 或 JPA 的大小将增加一倍以上。您可以准确地量化多少。并且有不止一个 JAR，因为它们都有依赖关系。
YAGNI says that you should keep it simple. It's five tables!
YAGNI 说你应该保持简单。是五桌！
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.
更改供应商（如果操作正确）意味着切换 JDBC 驱动程序 JAR、更改驱动程序类名称并添加新的连接 URL - 无论您选择哪种技术，您都必须这样做。
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.
你打算用哪一个发货？HSQL 或需要安装 MySQL 之类的东西？这是一个更相关的问题。
回答by Bozhidar Batsov
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.
如果您想使用对象关系映射，JPA 肯定是要走的路——它与实现无关（意味着您可以将它与 Hibernate、Toplink 等一起使用）并且它是事实上的标准。Hibernate 有更丰富的特性集，但这是一个非标准的解决方案——虽然很多人使用它......我个人总是使用 Hibernate 支持的 JPA。我尽量远离休眠特定的东西，但如果需要它 - 它就在我身边。
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.
不过，对 5 个表使用 JPA/Hibernate 等框架可能有点矫枉过正。您的应用程序将大 5MB 左右，并且会消耗更多的内存。您可以简单地选择将 JDBC 与 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.
由于 JDBC 使用特定于供应商（数据库）的 SQL，因此您计划使用不同的数据库时可能会出现问题。JPA 在这方面具有明显的优势。
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 :-)
无论您选择什么，您都不会出错 - 您需要问自己的主要问题是增加的大小和内存消耗是一个问题，您是否愿意编写样板 DAO JDBC 代码。我通常讨厌这个:-)
