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?