How NOT to choose the WRONG persistence framework for your Java project!

Introduction

Currently, the most popular Java persistence framework is Hibernate . Hibernate is an ORM (Object relational mapping) system.
ORM systems map Java objects to a relational database with very little code development.

Other ORMs include SUN's JPA and TOP Link .

Many people will quickly decide on using an ORM without realizing the pitfalls of using an ORM or without looking at other persistence frameworks.

The other options include a Data Mapper tool like Ibatis or by creating their own custom framework using JDBC and SQL.

See this link for a list of existing persistence frameworks

So the three types of frameworks are :

ORM - Object Relational Mapping
Data Mapper - Easily maps JDBC data into a Java object.
Custom JDBC/SQL

Pros and Cons

Lets look at some of the pros and cons of each framework.

ORM - Object Relational Mapping

Pros

Very little code to write which leads to rapid development
Built in caching for quick access
Database Independence

Cons

No SQL code which means you can't tune SQL queries.
Doesn't't work well with multiple databases.
Doesn't work well when database model and object model are very different.
Doesn't work well with Stored Procedures.

Data Mapper

Pros

Uses native SQL code. Able to tune problematic queries
Integrates with Object model
Works well with Stored Procedures.

Cons

More code to write and maintain then an ORM.

Custom JDBC/SQL

Pros

Very flexible. Easy to integrate multiple data sources and databases.

Cons

LOTS of code to write and maintain
Developed code can be very buggy.
Steep learning curve for new developers

Decision Process

All things being equal, the best choice for Java persistence is an ORM.

However, all things are not equal. Pesky things like legacy databases and data sources and legacy code can get in the way and cause problems.

Really, there is no simple black and white answer for which persistence framework to use. There are certain strengths and weaknesses of each framework that must be viewed in relation to your Java environment.

From this analysis, the "right" java persistence framework can be chosen.

In the real world, a combination of one or more of these frameworks may need to be utilized to meet your requirements.

Why would you use an ORM

Need rapid development and database Independence.
Starting a new project with a new database. No other legacy databases involved.
The domain model and the database model are in synch with each other.

Why would you NOT use an ORM

Starting a new project that utilized one or more legacy databases and the legacy database model is out of synch with the new domain model. There will be a continuous battle of trying to map the database model to the new domain model

Lots of stored procedures.
A complex database model that requires complex SQL queries.

If you go thru the above decision process and the only negative is complex SQL queries, you may still use the ORM because most ORMs allow for native SQL to be executed.
The other option would be to incorporate a data mapper or custom JDBC to provide the complex SQL functionality to the ORM framework. The only issues with this approach is to make sure that the SQL is read only and is not being used within an ORM transaction.

Why would you use a data mapper

Lots of complex SQL queries.
Lots of stored procedures.
Working with legacy databases and the domain model and the database model are not in synch.

Why would you NOT use a data mapper

Want to reduce the overall amount of code
Don't want to write any SQL code.

Why would you use a custom JDBC/SQL framework

In general, you would not want to rely solely a custom JDBC/SQL framework. Its best utilized in combination with an ORM or a data mapper.