Explaining the concept of the data-access object pattern

In the business world, the application always needs to be integrated with the data source in order to read, write, delete, or update data. This data source could be a relational database, NoSQL database, LDAP (Lightweight Directory Access Protocol), or filesystem, for example. Each type of data source has its structure and has a complexity to connect to, read, and write data. These complexities shouldn't be exposed to business logic and instead should be decoupled from it.

The data-access object pattern is a pattern used to abstract and hides all access to data sources from the business tier. This pattern encapsulates all data-source access logic and its complexities from the business tier, decoupling all data-source access logic from it. If we then want to substitute the data source with another, we will only need to modify the code of the data-access object pattern, and this modification will not be visible on the business tier. The following diagram displays the data-access object pattern model:

In the preceding diagram, we have BusinessObject, which has the business logic; DAO, which has the data access logic; TransferObject, which is the object used to transfer; and data source, which is the external local where the data resides. When BusinessObject needs to access the data, it requests data from DAO. The DAO accesses the data source and reads the data, then returns the data to BusinessObject as TransferObject. Some developers and professionals think this pattern is only supposed to be used with relational databases and NoSql, but when our data source is a filesystem or another type of data persistence, we should also use DAO in order to promote the decoupling between business logic and persistence logic as well as to organize our code.