The DAO design pattern essentially separates the business logic from your persistance logic. What does that actually mean? Lets say you want to create a food order online. When you submit the request, that object request would need to be stored within a database repository, which would require the program to create database connection (persistance), submit a URL, ensure JDBC classes are available etc. Though you don't care about any of the techy stuff, you're hungry and all you want is that food!

So the request must be segregated from what is required, hence the business logic must be separated from the persistance logic.

Along with the segregation, you have have persistance of the object that the client creates though don't require the client to maintain the persistance of the object

You often see that the client will have direct communication to the DAO, which is very misleading because DAO is a conceptual design and not a specific 'thing'. The initial communication to the DAO is basically the interface, which is connected to the factory, which will then determine which data source to use.

This sounds very much like an interface/class design (factory Design) though the DAO has a specific logic called the 'transfer object'. This transfer object is basically a class that the DAO creates and the client can update to.

• Order - All the components to create a specific object (burger type, how you like it, do you want gerkins etc)
• DAO - When you've created the object, you send it to the DAO (which is simply the interface to the factory). The DAO is responsible for updating within he transfer object and deleting it within the transfer object is requested
• Transfer Object - When the DAO receives the object, the DAO will 'transfer' that object into the transfer object repository, which in it's simplistic fashion is just like the order though contains all the 'getter and setter' methods.
• Factory - Responsible for creating the persistance data source. So it will create the source based on the data you sent over within the object

• Order Object
All the specific method associated to the object + getObjectTransferObject() (which is basically getting the object you created though it now resides within the 'Transfer object' class
• DAO methods
It's an interface, so it contractually obligated to hold the methods located within the factory so it's methods such as the following:
• updateOrder
• insertOrder
• deleteOrder
• Transfer Object
Contain such methods such as the following:
• This is basically the object + getter and setters method

About the author