Everyday Coder

This is my inaugural post. I guess I should hit the ground running with a post concerning database access from Java applications. I'm in the minority in that I'm currently writing a stand-alone Java application, not a JEE Enterprise Application. I know that this may be a shock to some of you, but let's just keep moving.

I used to be in the Roll Your Own camp when it came to database persistence. I'd create a set of classes roughly separated along table boundaries. Those classes would call the classes in the java.sql package directly. This method seemed to work just fine, but it did take a lot of work to get all the code setup to convert ResultSets to real objects. I actually used that method several times in the past with great success. My only regret is that my internal object model usually mapped exactly to my tables -- meaning that references were often represeted by id's rather than an actual object reference.

As new projects arose, I found myself searching for something better suited to persisting objects from my data model. My next attempt was to use Hibernate. The most attractive feature that Hibernate offered was forced separation of the persistance layer and the Java object model. We eventually got Hibernate up and running and the project was done.

Hibernate left a bad taste in my mouth. It seemed that I spent a *lot* of time learning their object querying language as well as fiddling around with the XML mappings. I would much rather have spent the time adding additional features to the software. I know that one of the most attractive reasons that people use Hibernate is that the underlying database can change without too much effort. Sadly, this feature is flat-out usless to me. I have never once had management come to me and force me to change my DB.

I decided to be a little more drastic on my next project and I went with Prevayler. For those of you not familier with Prevayler: it's an object persistence layer relying on Java's object serialization with added transaction support. I have to say that I was pretty enthusiastic after reading up on Prevayler. Prevayler turned out to be a good fit for that application. My only complaint is that I had to create a boat load of transaction objects. I ended up with 50+ classes that handle the individual transactions within the object model. So basically, if I wanted to change a user's first name, I would create a ModifyUserTransaction passing in the new field values and that would perform the modification. Seemed like a lot of work.

Prevayler also left a sour taste in my mouth. I just hated having a package full of classes that were basically one line-ers. Anyway, it did work and given my previous battle with Hibernate, I was happy to see that no XML configuration files were needed. Also, the objects were all stored as serialized java objects in a snapshot file that could easily have been read by another Java application.

Then came my current project. This time, I'm forced to use an SQL server backend. Mostly due to the fact that we will want to take advantage of the stability and host it in a centralized location. I know that a lot of you would have immediatly jumped for the 3-tier JEE architecture. I, myself, chose to do an old-fashioned client-server application. This application will ultimatly communicate via JDBC to the native protocol for the database.

For this attempt, I've deviced to use the SpringFramework's JDBC API. After much reading this seems like a good choice. I'll let ya'll know how it turns out.

After reading back over this post, I realize that it may have rambled a bit, but I'll leave it as-is. After all, I'm just a lazy programmer.

Trackback URI | Comments RSS