DAO

Contents

Design Patterns
1
Design Patterns
PREVIEW2m 26s
2
Singleton Pattern
PREVIEW3m 13s
9
Decorator
7m 48s
10
Flyweight
9m 20s
11
Proxy
7m 36s
12
Facade
6m 5s
14
Command
11m 44s
15
Iterator
8m 24s
16
Visitor
9m 4s
17
Mediator
11m 38s
18
Memento
9m 48s
19
Observer
10m 40s
20
Strategy
8m 27s
21
State
10m 27s
22
Template
7m 56s
23
MVC
10m 27s
26
DAO
10m 27s
27

The course is part of this learning path

Start course
Difficulty
Intermediate
Duration
4h 56m
Students
55
Ratings
5/5
starstarstarstarstar
Description

This course takes an in-depth look at how to use design patterns in your Java projects. We will then run through some example questions of what you could expect from the Oracle Certified Java EE exam.

Learning Objectives

  • Understand what design patterns are
  • Learn about the myriad of design patterns that you can use in your projects

Intended Audience

This course is intended for anyone who already has basic knowledge of Java and now wants to learn about Java EE 6.

Prerequisites

Basic knowledge of Java programming.

 

Transcript

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.

 

About the Author
Students
1911
Courses
64
Learning Paths
4

OAK Academy is made up of tech experts who have been in the sector for years and years and are deeply rooted in the tech world. They specialize in critical areas like cybersecurity, coding, IT, game development, app monetization, and mobile development.

Covered Topics