Hibernate or JPA or JDBC or? [closed]

by

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.

Leave a Comment