My examples were intended to point out that such a design isn't necessary, and to discuss the article you linked.

A data manager is there to provide an interface to the database. Whether that's a one-to-one mapping or not depends on the types of operations you need to perform. I have another query that returns calculated data and history from a nested view. The objects being created consist of a data object with a collection of history objects. Neither of these represents the actual structure of the data within the database.

I will point out, however, that typical CRUD applications will have a one-to-one mapping, since they are basically table maintenance applications.

A data manager is also intended to localize required changes when a schema changes. But schema changes are schema changes. At the very least you're going to have a change in the form that creates the data, a change somewhere in mapping code (unless there is an exact one-to-one relationship and you can do this automatically), in any stored procedures wrapping the table, and the table itself. With a data manager, none of the query/update code in the rest of the application changes (other than field additions, perhaps), because the interface is confined to one location. In fact, you can swap out a data manager with a mock data manager that provides and manipulates canned data for consistent unit testing of the rest of the application, and none of the other code will know the difference.

I would point out that, while I used it in the example, the technique of passing a recordset to an object to construct itself is only useful when you have non-hierarchical data being returned. In Oracle I have an Oracle object mapping library that automatically maps database object types to Java beans using reflection.

Perhaps the discussion will be more fruitful if you describe the sort of framework that you would rather use?

Some of his observations are correct, but the conclusions he draws are iffy. Notice that after he slags Spring, he uses straight JDBC in his comparison examples.

but it required creating a subclass for each query

Incorrect:

counter = new SqlFunction(ds, "select count(quote) as lrpdcount from quote where board_id = ?");\ncounter.declareParameter(new SqlParameter(java.sql.Types.INTEGER));\ncounter.compile();\nSystem.out.println(counter.run(boardId));

where ds is a bog standard JDBC datasource instead of his own pooling object (who writes their own pooling objects these days? Wait, don't answer that...). See the user queries below as well.

His example with the recordset is a bit disingenuous, since very rarely do you just want to print out a tabular query result. See the last example below.

learning a somewhat complicated exception hierarchy

As Chris pointed out, the exceptions are unchecked. If your exceptions signify a fatal condition (which is most of the time), then you want them handled by a central handler, and you don't have to know jack about the exception hierarchy.

Here's the equivalent code to his error checking example (except that I actually used braces like you should, instead of trying to make the code look tiny by omitting them...):

try { some data access code here }\ncatch (DataIntegrityViolationException v)\n{\n    applyDataIntegrityViolationRecovery();\n}\ncatch (DeadlockLoserDataAccessException d)\n{\n    applyDeadlockRecovery();\n}

So, learn a slightly complicated exception hierarchy, or learn a slightly complicated method call API. Note that an exception hierarchy allows you to stack your error handling more easily without if/then tests in each stack.

Looks to me like he copied Spring with a slightly different API (and probably a lot less functionality). Some of what Spring does allows you to manage your transactions outside of the data access code itself, for example. Spring also allows you to use things like Toplink or Hibernate with the same exception handling.

requiring framework users to implement anonymous inner classes.

this.allUsersQuery = new MappingSqlQuery(ds, "SELECT * FROM users")\n{\n    protected Object mapRow(ResultSet rs, int count) throws SQLException\n    {\n        return new User(rs);\n    }\n};\nthis.allUsersQuery.compile();\nList users = this.allUsersQuery.execute();

<dry>Oh, that was difficult.</dry> Notice the convenient lack of loop processing to run through the result set, such as SQLExecutor requires.

Or if you want to parameterize it:

this.userQuery = new MappingSqlQuery(ds, "SELECT * FROM users where user_id = ?")\n{\n    protected Object mapRow(ResultSet rs, int count) throws SQLException\n    {\n        return new User(rs);\n    }\n};\nthis.userQuery.declareParameter(new SqlParameter("user_id", Types.VARCHAR));\nthis.userQuery.compile();\nUser u = (User) this.userQuery.findObject("spork");

Owing to Spring's callback nature, you can do a lot fancier things as well, such as processing a stored procedure's returned cursor transparently.

Now, you're not strictly required to subclass things to do your queries, but if you do, you can create a more object-oriented approach to data access. I'm not sure why he thinks this is a bad thing.

Example combining the above:

private class UserQuery extends MappingSqlQuery\n{\n    public UserQuery(DataSource ds)\n    {\n        super(ds, "SELECT * FROM users");\n        compile();\n    }\n\n    public ViewRegMappingSqlQuery(DataSource ds, String where)\n    {\n        super(ds, "SELECT * FROM users WHERE " + where);\n    }\n\n    protected Object mapRow(ResultSet rs, int count) throws SQLException\n    {\n        return new User(rs);\n    }\n}\n\nthis.allUsersQuery = new UserQuery(ds);\n\nthis.userQuery = new UserQuery(ds, "user_id = ?");\nthis.userQuery.declareParameter(new SqlParameter("user_id", Types.VARCHAR));\nthis.userQuery.compile();\n\nthis.loginQuery = new UserQuery(ds, "user_id = ? AND password = ?");\nthis.loginQuery.declareParameter(new SqlParameter("user_id", Types.VARCHAR));\nthis.loginQuery.declareParameter(new SqlParameter("password", Types.VARCHAR));\nthis.loginQuery.compile();\n\nthis.lemurQuery = new UserQuery(ds, "country = 'Madagascar'");\nthis.lemurQuery.compile();

Now, granted he does say that he's just trying to make a very simple SQL framework, but I really don't see the added benefits. And as soon as you do something that he didn't allow for in his framework, you're reduced to either using straight JDBC, mixing frameworks, or rewriting the entire thing. I'll go with the tool that I know can handle anything to start with.

[Edit: slight formatting changes, fixed bug with WHERE clauses in last example]

Error in transcription, sorry.