Hello, dear friends. In this video, we will examine the DAO pattern. So, let's begin. In software, a DataAccessObject called DAO 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 Java EE applications and with relational databases. 

The DataAccessObject pattern allows us to isolate the application/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 DataAccessObject 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 is the object that requires access to the data source to obtain and store data. A 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. Data source represents a data source implementation. A data source could be a database such as an MS SQL, Postgre 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 DataAccessObject may use a TransferObject to return data to the client. The DataAccessObject may also receive the data from the client in a TransferObject to update the data in the data 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 DataAccessObjects 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 DAO layer and not all the places in the domain logic where the DAO layer is used from. The disadvantage of DAO is that

it is not useful with CMP entity beans. Okay, I think it's time to create a simple project using the DAO Pattern. Create a new project and name it DAO. 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. First, import List library. In interface, we  need CRUD methods and getAllEmployee method. Now, we will define concrete classes. EmployeeDAO, implements DAO. Define employee list. In constructor, we will fill the list. Okay, done, now we have to override all methods one by one. addEmployee, getEmployees, updateEmployee, deleteEmployee. The 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. Okay, 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 DAO pattern. In the next video, we will examine the domain store design pattern. So, I'll see you in the next video my friends.