There are other “issues” too that you alude to, such as:

1) The succession of one framework over another, creating a problem for legacy systems on where to go next.

2) Framework upgrades requiring the legacy system to either keep up, or risk being left behind.

3) Vendor or framework lock in.

To take an Oracle example, I’ve seen one site heavily use Oracle’s Headstart, a very old Oracle Forms & Designer framework, which then died a slow death, leaving the site stuck with code they neither owned or could receive upgrades for.

CM.

The exceptions get translated to a subclass of DataAccessException which is a runtime exception. This is true for both JDBC and all other data access technologies supported by Spring. That way your application don’t need to worry about all the different exception hierarchies.

Thomas

Exactly. Like I said, if I was working on a project using Spring already, then I’d probably make use of the Spring JDBC template.

Sometime I’ll research how the JDBC Template is handling exceptions, that is one thing that struck me when looking at the example code, there aren’t any being thrown. I would assume that they aren’t actually buried, but the if they aren’t then the exception handling being done inside that framework is a little less than obvious. Of course, I didn’t actually try the example code, so perhaps it is ignoring the exception handling.

My intention with this post wasn’t so much to pick on Spring at all, it’s a decent framework for what it does, it was to point out that not all attempts to abstract complexity work, a lot of times they just move that complexity around.

Introducing a framework does bring a bit of a learning curve and isn’t something you should do without analyzing the benefits. If you have an application with extremely simple data access requirements, then yes, using a framework might not pay off immediately. However, looking at it long term and if you develop a number of applications then the JDBC framework investment quickly pays off.

It’s more than just the code to make the call. Any data access operation is part of an application and, except for an extremely simple application, you will at some point move beyond the autocommit mode. Now you need to manage your transactions. If you write code both for a standalone and a managed J2EE environment, the transaction management is very different and you can’t easily re-use code in the different environments. Using a framework like Spring gives you this transaction management on top of the JDBC framework and the transactions become transparent to your application.

Another issue with straight JDBC code is the resource management and try/finally blocks that tend to obscure the actual data access logic. Moving these concerns to the framework not only prevents the JDBC programmer from messing this part up, it also makes your code more readable and maintainable.

Thomas

If I was working on a project that used Spring already, I’d probably look harder into using the Spring JDBC Template or SimpleJdbcCall, but if I’m not, JDBC itself is simple enough for me.

If you look at the new SimpleJdbcCall you’ll see a simplified approach where parameters don’t need to be declared if the framework can look them up in the database metadata.

Here is the SYSDATE example using SimpleJdbcCall:

SimpleJdbcCall callSysdate =
new SimpleJdbcCall(dataSource)
.withFunctionName(”sysdate”)
.withoutProcedureColumnMetaDataAccess()
.declareParameters(new SqlOutParameter(”return”, Types.DATE));
Date sysDate = callSysdate.executeFunction(Date.class, Collections.EMPTY_MAP);
System.out.println(”–> ” + sysDate);

This is assuming that you already have the DataSource available. Since SYSDATE is a built in function there is no metadata to look up so we need to turn off the metadata lookup and explicitly configure the out parameter.

Thomas

It would take more time than the average reader would spend reading a blog entry to get a good handle on the capabilities of ADF in the security realm, so let me power-off by saying that ADF’s approach to security going forward is one of the more exciting developments in the sphere of internet application development. ADF is preparing for a world where applications are much more than a series of pages.