Hello, dear friends. In this video, we will examine the D-A-O pattern. Let's begin. In software, a data access object called D-A-O is a pattern that provides an abstract interface to some type of database or other persistence mechanism. By mapping application calls to the persistence layer, the DAO provides some specific data operations without exposing details of the database. This isolation supports the single responsibility principle. It separates what data access the application needs in terms of domain specific objects and data types from how these needs can be satisfied with a specific DBMS or database schema. Although this design pattern is equally applicable to most programming languages, most types of software with persistence needs and most types of databases, it is traditionally associated with the Java EE applications and with relational databases.

The data access object pattern allows us to isolate the application or business layer from the persistence layer using an abstract API. The API hides from the application all the complexity of performing CRUD operations in the underlying storage mechanism. This permits both layers to evolve separately without knowing anything about each other. As you can see in this UML, DAO has four participants. The DataAccessObject is the primary object of this pattern. The data access object abstracts the underlying data access implementation for the business object to enable transparent access to the data source. The business object represents the data client. It's the object that requires access to the data source to obtain and store data. The business object may be implemented as a session bean, entity bean, or some other Java object in addition to a servlet or helper bean that accesses the data source. DataSource represents a data source implementation.

A data source could be a database, such as an MS SQL, Post GRE, or Firebase. A data source can also be another system service or some kind of repository. TransferObject represents a transfer object used as a data carrier. The data access object may use a transfer object to return data to the client. The data access object may also receive the data from the client in a transfer object to update the data in the source. As I said, DAO pattern is used to separate low-level data accessing API or operations from high-level business services. The advantage of using data access objects is the relatively simple and rigorous separation between two important parts of an application that can, but should not know anything of each other and which can be expected to evolve frequently and independently. If we need to change the underlying persistence mechanism, that will be enough to change only the down layer and not all the places in the domain logic where the down layer is used from.

The disadvantage of the DAO is that it is not useful with CMP entity beans. Now, I think it's time to create a simple project using the D-A-O pattern. Create a new project and name it D-A-O. First, we will create our value object and name it Employee. Define properties as name, job, and registration number. Generate getters and setters. Now, we will create our DAO interface. In interface, we need CRUD methods and getAllEmployee method. First, import List library. Now, we will define concrete class, EmployeeDAO implements DAO. Define employee list. Add the constructor. In constructor, we will fill the list. Done. Now, we have to override all methods one by one: getEmployees, addEmployee, and getEmployee, updateEmployee, deleteEmployee. Structure is ready, let's test it. First, define a DAO from EmployeeDAO. I want to use a loop to show all employees. Now, let's update second employee. Done. Let's try. As you can see, Charles Dickens was updated with Aldous Huxley. I hope you now have a better understanding of the D-A-O pattern. In the next video, we will examine the domain store design pattern. See you in the next video.