Data Access Object DAO

DAO is really a ** J2EE pattern **. It is very easy to implement in PHP and it helps enormously to separate the access to the database from the rest of the code. DAOs are usually treated as a thin layer. The DAO layer can be ‘stacked’ which helps for example if we want to add database caching when we want to improve the application.

The Problem

Most applications have to persist data at some point, either by serializing it, saving it in a relational database, an XML file, etc.

To do this, the application interacts with the database. The “how it interacts” should NOT be a matter for the application’s business logic layer, since that’s what the persistence layer is for, which is in charge of interacting with the database.

Knowing this, we can say that DAO is a design pattern used to create this persistence layer.

Why do we want a layer of persistence?

Well, let’s imagine we made an ecommerce application for our company. Using MySQL as a database engine. But we don’t have the business logic layer divided from the persistence layer. So the interaction with the database is done directly from the business logic layer. Our application consists of many PHP scripts, and most of them interact with the database (connecting to it, saving and retrieving data, etc.).

Our application works perfectly but our system administrator advises us that all the company’s applications are going to migrate to the PostgreSQL database engine for X, Y and Z reasons.

If we had had the business logic layer separately from the persistence layer, it would have been enough to modify the persistence layer so that the application could use the new database engine, without having to modify anything in the logic layer of deal. So we are going to have to modify all the PHP scripts by changing all the SQL queries, the way to access the database, etc. to accommodate the new database engine.

Okay, now that we know why it is important to have the business logic and persistence layers separate, let’s see how to use the DAO design pattern to create our own persistence layer.

As mentioned above, we must try to ensure that our PHP classes or scripts do not have more than one responsibility, such as, for example, that in addition to accessing the database it has responsibilities for business logic.

Another interesting example. Suppose that in an application for a library we had a class ** GestorPrestamos ** that would take care of making and managing book loans. In a first approximation we could make this class take care of both the business logic (for example, checking if a user is “delinquent” before lending him a book) and access to data (entering the loan in a hypothetical loan table) .

This type of approach leads to systems that are not very modular and difficult to maintain. In our case, the change in the business rules would imply changes in ** GestorPrestamos **. The problem is that in addition, a change in the database also implies changes in ** GestorPrestamos **

To achieve greater modularity and divide responsibilities, we would have to carry the data persistence in a separate class and leave ** LoanStream ** only with the business logic.

Solution

As mentioned above, in any project the persistence of data must be separated from the rest of the system’s functionalities. That layer would be the one that would be in charge of accessing the data source through the DAO pattern

The DAO pattern will manage the connection with the data source to obtain and store information in it, so if in the future we change databases we would only have to modify the DAO layer.

As discussed above, DAO encapsulates access to the database. So when the business logic layer needs to interact with the database, it will do so through the API that DAO offers. Generally this API consists of CRUD methods (Create, Read, Update and Delete). For example, when the business logic layer needs to save data to the database, it will call a create () method. What this method does, is a DAO problem and depends on how DAO implements this method, it may implement it so that the data is stored in a relational database as it may implement it so that the data is stored in files of text. The important thing is that the business logic layer does not have to know, the only thing it knows is that the create () method will save the data, just as the delete () method will delete it, the update () method will update it, etc. But you have no idea how DAO interacts with the database.

In an application, there are as many DAOs as there are models. That is, in a relational database, for each table, there would be a DAO.

DAO basically consists of a class that is the one that interacts with the database. The methods of this class depend on the application and what we want to do. But generally CRUD methods are implemented to perform the “4 basic operations” of a database. For example, when the business logic layer calls the create () method, what does DAO do? insert a new data but what data? the one that the business logic layer passes as a parameter.