Tutorials About

The DAO Design Pattern

Last updated: 2014-05-21

The Data Access Object (DAO) pattern is now a widely accepted mechanism to abstract away the details of persistence in an application. The idea is that instead of having the domain logic communicate directly with the database, file system, web service, or whatever persistence mechanism your application uses, the domain logic speaks to a DAO layer instead. This DAO layer then communicates with the underlying persistence system or service.

Here is how it looks:

The advantage of the DAO layer is that if you need to change the underlying persistence mechanism you only have to change the DAO layer, and not all the places in the domain logic where the DAO layer is used from. The DAO layer usually consists of a smaller set of classes, than the number of domain logic classes that uses it. Should you need to change what happens behind the scene in the DAO layer, the operation is somewhat smaller, since it only affects the DAO layer. It is also a somewhat more controlled operation, since you can search for all DAO classes, and make sure they are changed to use the new persistence mechanism.

For this encapsulation of the underlying persistence mechanism to work it is important that no details of the underlying persistence mechanism leak out of the DAO layer. Ensuring this is, however, a bit of a challenge, as I show you in the next text in this trail.

Connect with me: Newsletter - Get all my free tips!

Close TOC
This website uses cookies to improve the user experience and gather statistics. Our advertisers use cookies too (3rd party cookies), to provide more relevant ads. Continued use of this website implies that you accept the use of cookies on this website. We do not share our cookies with our advertisers, and our advertisers do not share cookies with us.