DAO isn't a mapping. DAO stands for Data Access Object. It look something like this:
public interface UserDAO {
public User find(Long id) throws DAOException;
public void save(User user) throws DAOException;
public void delete(User user) throws DAOException;
// ...
}
For DAO, JDBC is just an implementation detail.
public class UserDAOJDBC implements UserDAO {
public User find(Long id) throws DAOException {
// Write JDBC code here to return User by id.
}
// ...
}
Hibernate could be another one.
public class UserDAOHibernate implements UserDAO {
public User find(Long id) throws DAOException {
// Write Hibernate code here to return User by id.
}
// ...
}
JPA could be another one (in case you're migrating an existing legacy app to JPA; for new apps, it would be a bit weird as JPA is by itself actually the DAO, with e.g. Hibernate and EclipseLink as available implementations).
public class UserDAOJPA implements UserDAO {
public User find(Long id) throws DAOException {
// Write JPA code here to return User by id.
}
// ...
}
It allows you for switching of UserDAO implementation without changing the business code which is using the DAO (only if you're properly coding against the interface, of course).
For JDBC you'll only need to write a lot of lines to find/save/delete the desired information while with Hibernate it's a matter of only a few lines. Hiberenate as being an ORM takes exactly that nasty JDBC work from your hands, regardless of whether you're using a DAO or not.
See also:
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
