Hibernate or JPA or JDBC or? [closed]

Answer 1

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 :-)

Answer 2

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.

Answer 3

For this scale anything will work allright. Consider iBatis as well.