Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Simple classes for JDBC

Avoid the tedium of JDBC programming

By Madhu Siddalingaiah, JavaWorld.com, 06/07/04

Call me a troublemaker. I know what you are thinking. Yet another tool/wizard/API/framework to complicate your life. I can understand your hesitation: the problem of object-relational mapping has been kicked around for years. Everyone has a solution that is easier, better, faster, cheaper. Why do we need more code that probably does what someone has already done somewhere else? Two reasons: Most of the solutions appear more complicated than necessary, and they require a significant commitment. Once you buy in, it's hard to get out.

I like things simple. A colleague recently shared a nice quote:

"Simplicity leads to ubiquity, complexity leads to obscurity."

And we've all heard the Einstein quote:

"A scientific theory should be as simple as possible, but no simpler."

Here's one from James Gosling himself:

"Complexity is in many ways just evil. Complexity makes things harder to understand, harder to build, harder to debug, harder to evolve, harder to just do about everything."

I could go on and on. There are many examples of complexity, too many. In the case of database access, you can use entity beans, or an object relational mapping tool, or the latest open source framework. I don't have a formal complaint against any of those tools; I'm certain their authors had a great vision in mind when developing them. For me, today, I want something simple.

Charting the latitudes

Let's step back a bit. Most of the time, an application needs to take information from a user and create/edit/delete/view it as rows in a database. One important detail is that information to and from the user must be in the form of a string. This means that validation/parsing has to be done on the way in and formatting, on the way out. This is not hard, but it's repetitive and involves numerous annoying null checks. Another important feature that users have come to expect are the so-called VCR controls: the ability to page through a large set of results or jump to the end, not easy to do with a ResultSet alone.

One popular solution is to manually or automatically map SQL results and table schemas to objects and classes. At the outset, this appears reasonable, if not natural. In general, database modelers and object modelers try to accomplish the same thing: manage business information in a logical and extensible manner.

Unfortunately, the honeymoon ends there. Object modelers prefer to isolate themselves from the sundry details of how data goes in and out. To some, the database is just a big hashmap with more than one key. This might be an accurate assessment, but there is a tricky SQL animal known as the table join. Database experts argue that joins give relational databases their power. Object modelers might look at a join as an untamed beast that just causes more trouble than it's worth. Regardless of your opinions, objects and databases are not likely to change significantly in the near future. Applications and business logic will continue to use objects, and data persistence will continue to take the form of a relational database.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.