when to use Hibernate vs. Simple ResultSets for small application

Question

I just started working on upgrading a small component in a distributed java application. The main application is a rather complicated applet/servlet combo running on JBoss and it extensively uses Hibernate for its DataAccess. The component i am working on however is very a very straightforward data importing service.

Basically the workflow is

1. Listen for a network event
2. Parse the data packet, extract a set of identifiers
3. Map the identifier set to a primary key in our database
4. Parse the rest of the packet and insert items in a related table using the foreign key found in step 3
5. Repeat

in the previous version of this component it used a hibernate based DAL, that is no longer usable for a variety of reasons (in particular it is EOL), so I am in charge of replacing the Data Access layer for this component.

So on the one hand I think i should use Hibernate because that's what the rest of the application does, but on the other i think i should just use regular java.sql.* classes because my requirements are really straightforward and aren't expected to change any time soon.

So my question is (and i understand it is subjective) at what point do you think that the added complexity of using an ORM tool (in terms of configuration, dependencies...) is worth it?

UPDATE

due to the way the DataAccesLayer for the main application was written (weird dependencies) i cannot easily use it, i would have to implement it myself.

Answer 1

I think the answer really depends on your skill set. It would probably take similar amount of time to craft a simple solution involving a handful of tables in either way (Hibernate or raw JDBC) if you are comfortable with both techniques.

As I am pretty comfortable with Hibernate, I'd just choose it as I prefer to working in a higher level and not worrying about things that Hibernate handles for me. Yes, it has its own glitches, but especially for simple data models it does the job, and does it well.

The only few reasons why would I choose plain JDBC would be:

• uber-complicated maximum-optimized SQL that is performance critical;
• Hibernate being stupid and not being capable to express what I want;

And especially if you say you are already managing other entities with Hibernate, why not keep your code in the same style everywhere?

Answer 2

I would avoid the "straight java.sql classes" approach if at all possible. I think the good choices are:

• Spring's JDBC-helper library
• Ibatis
• Hibernate

Spring-jdbc is good at hiding a lot of the ugliness of raw jdbc without getting in your way. Ibatis handles mapping sql result sets to pojos easily. Hibernate gives you an identity map, write-behind, lazy collections, and database independence.

Answer 3

I think you are better off using JDBC api. From what you describe, the two operations (select foreign key from table, insert into table_2) can easily be executed with a simple Stored Procedure call.

The advantage of using this technique is that you can manage transactions/exceptions within your stored procedure call.

Answer 4

If we look into why Spring-Hibernate combination is used? Because for simple Jdbc operation we have to do lot of operation like getting a connection. Making a statement and handling resultset.For all these steps there are lot of exception handling.

But with spring hibernate you have to use just this:

    public PostProfiles findPostProfilesById(long id) {
    List list=getHibernateTemplate().find("from PostProfiles where id=?",id);
    return (PostProfiles) list.get(0);
}

And everything is taken care by framework.I hope it will solve you dilemma