The DAO Design Pattern
Jakob Jenkov |
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.
| Tweet | |
Jakob Jenkov | |
