A Data Access Object (DAO) is a common pattern which helps to isolate your application’s code from the code that accesses and manipulates records in a database. In a larger architecture, a DAO provides a boundary between two separate architectural layers. We are introducing DAO objects in the context of the Spring Framework to give you a sense of how you can fit Hibernate into an overall system architecture, and we are introducing DAO objects because they represent a common pattern you will encounter in any real-world system that needs to interact with a database.
I’m always surprised when an author writes a twenty page description of the DAO pattern, its advantages, and its disadvantages. If you read the Sun J2EE blueprint, you’ll read a thick document explaining DAO creation patterns using factories and how the DAO pattern fits into the larger approach to enterprise application development. We’re going to skip much of the formality and just sum up the DAO pattern in two simple bullet points. The DAO pattern:
Consolidates all persistence operations (create, read, update, delete) into a single interface usually organized by table or object type.
Provides one or more swappable implementations of this interface which can use any number of different persistence APIs and underlying storage media.
Or, if you are looking for an even more compact definition: “DAOs hide all the gory details of persistence behind an interface.”
When you ...