Feedback
I've got some interesting feedback on the recent post. People write, that SQLJ compile time checks are not a big benefit, as soon as you are supposed to be writing unit tests. Well, I can say nothing more, than "I do agree!". Though, there are some different opinions, whether we should test our DAOs or not. Some people promote simulated DAOs, or mocking DAOs. Some people say - let each developer have his own instance of the database where (s)he would happily do whatever (s)he wants. There was a good discussion on TheServerSide.com, covering this problem: Article: A stepped approach to J2EE testing with Simulated DAO. I would say - it depends on a project and sometimes it'd make sense to run unit tests with mock objects, simulation DAOs on developer workstations in a development lifecycle and to run integration tests with normal DAOs on the integration environment.
There are some fans of stored procedures, who write about spaghetti code. Well, I think everybody had his(her) deal of spaghetti. Sad, but true.
SQLJ vs JDBC abstraction
People got used to ABAP development model. You write SQL code(or nearly SQL) in ABAP and don't think about anything else. Now these people start to program in Java. With SQLJ they immediately see Context, Iterator, SQLException, AutoCommit, whatever else. It's confusing. New technologies and I can say, very specific technologies. Why should people learn about it? Why not hide/encapsulate it? Ok, ok, don't bash me, you can't get away from Iterator in some form. But still you can write something like this: template.query("SELECT USER.NAME FROM USER", new RowCallbackHandler() { public void processRow(ResultSet rs) throws SQLException { names.add(rs.getString(1)); } });
This code example was taken from documentation to the Spring framework. Some time ago I implemented my own variant for handling JDBC connectivity code, it looked very similar. Ok, what about passing parameters to the query?(which can be moved out to the constants .java file, or even to .properties!) It can be an array of Objects, passed to the version of query method with 3 parameters. You'd say what's the reason for moving SQL code outside of Java code? Well, for example, DBA might want to have a look at the statements, that get issued to the database. Of course, it applies not to the majority of the projects, but only to those, where performance of SQL queries is crucial. When you have them in one place, it's much easier. Of course, SQLJ might have it's applicability, but what about refactoring support? And, final remark. These posts are my personal opinion, and may be the better place for them would be TheServerSide.com. And of course, I'd love to see a standard SAP component, abstracting JDBC connectivity code.
