Re: Non-ORM layers over JDBC

On Wed, 2008-03-26 at 11:21 +0100, Tore Halset wrote:
> Hello.
>
> On Mar 24, 2008, at 6:45 , Craig Ringer wrote:
> > I'm fairly new to Java (sorry!) and struggling with the database
> > access area.
>
> A newbie should not question if he should use a ORM, but instead focus
> on which ORM to use. Please spend some time finding a good ORM that
> you feel comfortable with.
>
> Why you should use an ORM:
> * Less boring code to write when bringing over data from PostgreSQL
> to your java application and back.
> * Simpler refactoring. What if you want to change the primary key,
> add a relationship or whatever.
> * Easier to support several databases. Thanks to Apache Cayenne, my
> app work with PostgreSQL, MS SQL Server and Derby and others.
> * And lots of other good reasons you will discover.
>
> When to not use an ORM:
> * Some specially tuned reporting queries

I'm the architect for a few large products that make heavy use of a
database, and I've worked fairly significantly both with raw JDBC and
with Hibernate. I'll be the first to admit that I don't know
everything, and my ORM experience is limited just to Hibernate, but
here's our experience for what it's worth.

If you're starting a new project (new DB, new code), then I would
definitely go with something like Hibernate or another ORM tool. Even
if you're used to writing straight SQL, it takes much of the tedium out
of working with the database and can be made to perform reasonably well
as long as you think before you type. You will need to do things the
"Hibernate way", but as long as you know that going in, it really
doesn't get in the way.

But if you are dealing with either existing code or an existing database
schema, my experience has been very different. Trying to adapt existing
object-oriented code to use Hibernate has proven to be extremely painful
because even though Hibernate is reputed to be an extremely configurable
ORM, many common object-oriented techniques just don't map very well and
you end up rewriting big chunks of code that you didn't expect to need
to. Like I mentioned above, code written without an ORM in mind just
won't map cleanly.

Trying to adapt Hibernate to an existing database schema is less
painful, but still seems more like an obstacle than a help, because a
design that makes sense in a relational world does not always (or even
usually) map cleanly onto an object-oriented world. You end up
generating somewhat exotic mappings and/or changing your database
structure just so your mapping works. It's rarely worth the effort.

Especially in the OP's case, where he already has an existing PG
database with large portions of the business logic in stored procedures,
I'd steer clear of ORM solutions.

For examples of using a database with a Swing GUI without an ORM layer,
you might want to look at the google results for "ResultSet TableModel"
or "Rowset TableModel" (note that I haven't used Rowsets in PG before,
they look promising and easier to use than ResultSets, but I have no
experience with how well they work in practice).

-- Mark