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

查看:28
本文介绍了Hibernate 或 JPA 或 JDBC 或?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个 Java 桌面应用程序,但在为我的持久层选择技术时有一些困惑.

I am developing a Java Desktop Application but have some confusions in choosing a technology for my persistence layer.

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

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.

现在我的问题是我的 Java 桌面应用程序使用什么?

Now my question is What to use for my Java Desktop Application from the following?

  • JPA

    • JPA

      休眠

      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

      1. 这不是一个复杂的应用程序.它只包含 5 个表(和 5 个实体)
      2. 我不想让我的代码灵活,以便我以后可以轻松地更改数据库
      3. 应用程序的大小应尽可能小,因为我必须通过互联网将其分发给我的客户.
      4. 必须可以免费用于商业开发和分发.

      ==================================== 编辑 ========================================

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

      基于以下答案,我想使用 JPA 以防止自己编写特定于供应商的 SQL 代码.

      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 中遇到了一些问题,Java Persistence API

      But I have some problems in JPA which are mentioned at Java Persistence API

      推荐答案

      这是我的看法:

      • JPA:在不将客户端耦合到 Hibernate、TopLink 等的情况下执行 Java 持久性的不可知方式.
      • Hibernate:如果您有要映射到的对象模型,则是不错的选择.
      • JDBC:所有 Java 持久性都建立在此之上.最低级别
      • DAO:与其说是技术,不如说是一种模式;CRUD操作界面.
      • iBatis:介于 JDBC(原始 SQL)和 Hibernate (ORM) 之间.
      • JDO:Java 数据对象,这是 Java 持久性的另一个规范.(例如,Apache JDO)

      这不是一个复杂的应用程序.它只包含 5 个表(和 5 个实体)

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

      这些都可以,但 JDBC 将是最简单的.所有其他的都建立在 JDBC 之上.

      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.

      使用 JPA 或 Hibernate 将需要 JAR,这会增加您的部署规模.JDBC 将最大限度地减少这种情况.

      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.

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

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

      如果您的对象以 1:1 的比例映射到您的五个表,我会说 JPA 是矫枉过正的平方.

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

      您的应用程序当前的大小是否为 3MB JAR?如果不是,则 Hibernate 或 JPA 的大小将增加一倍以上.您可以准确地量化多少.而且有不止一个 JAR,因为它们都有依赖关系.

      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 说你应该保持简单.是五桌!

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

      更改供应商(如果操作正确)意味着切换 JDBC 驱动程序 JAR、更改驱动程序类名称并添加新的连接 URL - 无论您选择何种技术,您都必须这样做.

      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.

      你打算和哪一个一起发货?HSQL 或需要安装 MySQL 之类的东西?这是一个更相关的问题.

      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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆