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.
无论您选择什么，都不会出错 - 您主要需要问自己的是增加的大小和内存消耗是否是一个问题，以及您是否愿意编写样板 DAO JDBC 代码。我通常讨厌这个:-)
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 :-)
发布评论
评论（3）
以下是我的看法：
其中任何一个都可以工作，但 JDBC 将是最简单的。所有其他的都构建在 JDBC 之上。
架构更改将在所有技术中产生类似的效果。
使用 JPA 或 Hibernate 将需要 JAR，这会增加您的部署规模。 JDBC 将最大限度地减少这种情况。
查看所有技术的许可证。对他们中的任何一个来说都不应该有问题。
仅供参考：可以编写一个通用的 DAO 接口：
如果您的对象与您的五个表 1:1 映射，我会说 JPA 是多余的。
您的应用程序目前的大小是 3MB JAR 吗？如果不是，那么 Hibernate 或 JPA 的大小将增加一倍以上。你可以准确地量化多少。而且 JAR 不止一个，因为它们都具有依赖关系。
亚格尼说你应该保持简单。一共五张桌子！
更改供应商（如果操作正确）意味着切换 JDBC 驱动程序 JAR、更改驱动程序类名称以及添加新的连接 URL - 无论您选择哪种技术，都必须执行这些操作。
我发现数据库并没有从根本上改变这一点。您将更改架构，但整个供应商呢？不太可能，尤其是当您有多个客户时。让用户群切换数据库将会带来很大的不便。
您打算与哪一个一起发货？ HSQL 或需要安装 MySQL 的东西？这是一个更相关的担忧。
Here's my take:
Any of these will work, but JDBC will be the simplest. All the others are built on top of JDBC.
Schema changes will have similar effects in all technologies.
Using JPA or Hibernate will require JARs that will add to the size of your deployment. JDBC will minimize this.
See licenses of all technologies. Shouldn't be a problem with any of them.
FYI: It's possible to write a generic DAO interface:
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 无疑是一个不错的选择 - 它与实现无关（意味着您可以将它与 Hibernate、Toplink 等一起使用），并且它是事实上的标准。
Hibernate 有更丰富的功能集，但这是一个非标准解决方案 - 尽管很多人都使用它......我个人总是使用 Hibernate 支持的 JPA。我尝试远离休眠特定的东西，但如果需要它 - 它就在那里为我服务。
不过，对 5 个表使用 JPA/Hibernate 等框架可能有点大材小用。您的应用程序将增大约 5MB，并且会消耗更多内存。您可以简单地选择将 JDBC 与 DAO 搭配使用。
由于 JDBC 使用特定于供应商（数据库）的 SQL，因此如果您计划使用不同的数据库，这可能会出现问题。 JPA在这方面具有明显的优势。
无论您选择什么，都不会出错 - 您主要需要问自己的是增加的大小和内存消耗是否是一个问题，以及您是否愿意编写样板 DAO JDBC 代码。我通常讨厌这个:-)
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 :-)
对于这个规模，任何事情都可以正常工作。也请考虑 iBatis。
For this scale anything will work allright. Consider iBatis as well.