Whereas I, always the contrarian, do not find it to be particularly useful.   I really don’t need a tool to write the SQL for me, especially since the SQL in an application, once written, rarely if ever changes.   (The notion that “you can just change the schema and you won’t have to change your code!” is something that has never worked-out for me in real life, since substantial database changes, when they occur, always precipitate deeper changes in logic.)   This is just me, and my opinion won’t buy you a cup of tea.

Also, I would want my “data acess objects” to completely conceal the existence of the database from all their clients ... not merely to provide, as it were, a database-API for them to use.   More than one of my data-access objects might well wind up interacting with the same database table or tables, should the implementation of the “application data ‘thing’” happen to wind up that way.   But, once again, just me, no tea.

So, who’s “right, wrong?”   No such luck.   There’s more than one way to do it.™   The design has to be clean and maintainable, for a very long time.   And, I think, it should always have a boots-on the-ground reason that is not merely philosophical ... that is very firmly grounded in your application at its present state.   Whatever you wind up with, it should visibly make your application easier to design and to maintain, and it should neatly encapsulate a fair amount of its complexity.   It will need to work easily alongside whatever older code the app already contains, without forcing itself upon the older code in order for either one of them to [continue to] work properly.   If you have an existing app with a substantial amount of database work already in place, seriously consider not trying to make it “–er” by introducing another different way to do the same thing.   In the end, it’s all an engineering judgment-call.