database - What way is better when executing queries from Java -

i have following doubt. when have query db java application there several ways it. have came approaches, each of them have con.

the first 1 is, have class eg. querymanager provides querying functionalities, executeupdate(...) , executequery(...) while hiding details of management of connections etc. (kind of facade pattern). when need interact db, pass query string , manage resultset.

the problem see if db changes, whether dbms or db itself, end going file file modifying sql. see huge dependency. also, exposing stucture of db , making each class handle resultset. on other hand, achive higher modularity using method, since models (i fan of mvc pattern) of classes have package visibility.

the second idea came mind creating querymanager class instead of providing methods querying, provide methods need. in other words, each time need use db, create method in class, sql inside, return information need. but, problem facing here is, have choose between returning resultset or model of data need.
former, make classes dependant on db, less in previous example, since there no spread dependency dbms, because sql contained in 1 class/file. still exists dependency db structure , exposing, well, db structure everyone.
later implies theese models no longer package visibility, must public, allowing class modify them, , breaking encapsulation.

is there other approach solves previous problems? if not, think better approach?

i not think there absolute answear (maybe there is), must expecting changes in both structure of db , in dbms. might in answear. try make general possible, since in other project same doubt, no same restrictions.

the second 1 one: should extract data access methods in data access objects (daos), isolate rest of application persistence-related problems. , daos should return objects, , not result sets.

this provides following advantages:

• decoupling of concerns , responsibilities
• easier evolution of rest of application when schema changes
• easier evolution of rest of application when choose use orm instead of jdbc access database
• easier unit-testing of queries (and of persistence layer in general), since persistence code not mixed functional code
• easier unit-testing of business (service) layer, because allows injecting mock daos provide data, rather needing real data in database test it.