Applying DAO and Object-Oriented Programming to Java Database Connectivity Project
305.3 - Applying Data Access Object and Object-Oriented Programming to Java Database Connectivity
Learning Objectives:
In this presentation, you will explore the Data Access Object (DAO) pattern, and apply the Object-Oriented Programming (OOP) concept and DAO pattern in JDBC application. By the end of this lesson, learners will be able to:
Describe the Design pattern and DAO Design pattern.
Demonstrate the DAO pattern.
Demonstrate how to apply the OOP concept and DAO pattern in JDBC application.
Applying Data Access Object and Object-Oriented Programming to Java Database Connectivity Project
Table of Contents
Overview of Design Pattern.
Usage of Design Pattern.
Data Access Object Patterns.
Data Access Object Pattern Components.
Applying OOP and Data Access Object to JDBC Application.
Before Data Access Object - Process of Java JDBC API.
After Data Access Object - Process of Java JDBC API.
Overview of Design Pattern
Authors, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software (1994), which initiated the concept of Design Patterns in Software development. The authors are collectively known as Gang of Four (GOF), and according to them, design patterns are primarily based on the following principles of object-oriented design (OOD):
Program to an interface, not an implementation.
Favor object composition over inheritance.
The software/application design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.
Design patterns are best practices that programmers can employ to overcome common design difficulties, and are solutions to general problems that software developers faced during software and application development. These solutions were obtained by trial and error by numerous software developers over a substantial period of time.
Usage of Design Pattern
Design Patterns have two main uses in software development:
Common platform for developers. Design patterns provide standard terminology and are specific to a particular scenario. For example, a Singleton design pattern signifies use of a single object so that all developers familiar with a single design pattern will make use of a single object, and can verify that the program is following a single pattern.
Best Practices for developers. Design patterns have evolved over a long period of time, and they provide best solutions to certain problems faced during software development. Learning these patterns helps inexperienced developers learn software design in a fast and easy way.
Data Access Object Patterns
Introduction
Data Access Object (DAO) is a pattern that provides an abstract interface to some type of database or other persistence mechanism.
DAO Design Pattern is used to separate the data persistence logic into separate layers. This way, the service remains completely in the dark about how the low-level operations access the database. This is known as the principle of Separation of Logic.
DAO is used to separate low-level data accessing API (like JDBC) or operations from high-level business services or the idea is to abstract or hide the database logic from the business layer.
Click here for more information about DAO.
The advantage of using data access objects
The advantage of using data access objects is the relatively simple and rigorous separation between two important parts of an application that do, but should not know of each other, and which can be expected to evolve frequently and independently. If we need to change the underlying persistence mechanism, we only have to change the DAO layer, and not all the places in the domain logic where the DAO layer is used.
Data Access Object Pattern Components
DAO - Data Access Object Interfaces - This interface defines the standard operations performed on the model object(s). The interfaces provide a flexible design.
DAO - Data Access Object classes - This class implements above the interface, and is responsible for getting data from a data source, which can be a database / xml or any other storage mechanism. The interface implementation is a concrete implementation of the persistence logic.
DAL - Data-Access Layer - DAL is made up of interface and implementation classes for DAO. This layer provides easy and simplified access to data stored in persistent storage, such as an entity-relational database or any database, in applications. This layer is between the Service Layer and the storage layer.
Model Classes / DTO - This object is a simple POJO class containing getter and setter methods to store data retrieved using DAO class.
DataSource: A data source could be a database such as an RDBMS, File,, XML repository, flat file system, or any other data source. A data source can also be another system service or some kind of repository.
Data Access Object Pattern Components (continued)
High-level Class Diagram representing the relationships for the DAO Pattern.
!https://i.imgur.com/8h8pFhE.png
Implementing the Data Access Object Pattern - Example 1
Let's use Books as an example. With DAO design pattern, we have the following components on which our design depends:
The Model class or the transfer object, which is transferred from one layer to the other.
The interfaces, which provide a flexible design.
The interface implementation, which is a concrete implementation of the persistence logic. We will use four components here:
The Book model class, which is transferred from one layer to the other.
The BookDao interface that provides a flexible design and API to implement.
The BookDaoImpl class, which is an implementation of the BookDao interface.
The main() method, which is the entrypoint of the application.
!https://i.imgur.com/5mXpWY5.png
Applying OOP and DAO to JDBC Application
We will now explore how to use DAO.
Before Data Access Object - Process of Java JDBC API
Let’s use the DAO pattern in a simple JDBC CRUD application.
Register the Driver - Same every time / Repeat.
Connect to the Database - Same every time / Repeat.
Prepare the Statement.
Execute the Statement.
Obtain data from the Database.
Close the connection - Same every time / Repeat.
After Data Access Object - Process of Java JDBC API
The New Process for JDBC Application with DAO
Start with AbstractDAO
Registers Driver.
Connects to Database.
Safely closes connection.
Create Interface for each DAO
Contains queries.
Structure for methods(CRUD).
Implement DAO
Write logic for interface methods.
Start with register/connect method.
End with close method.
Use business logic anywhere in the application. Before DAO, persistence code scattered within business logic. After DAO, new layer to encapsulate interaction with persistent.
!https://i.imgur.com/MKZiitS.png
Hands-On Lab: After DAO - Process of Java JDBC API
Find the GLAB 305.3.1- Building Java CRUD application using DAO pattern, OOP concept, and JDBC on Canvas under the Guided Labs section.
Practice Assignment
Create Table in Database:
Customer table:
id(int), email(varchar), fname(varchar), lname(varchar)
Item table:
id(int), name(varchar), price(decimal(4,2)).
Create models for each table.
Create DAOs with the following methods:
CustomerDAO
getCustomerById(int id) - Returns the customer object for the given id.
addCustomer(Customer c) - Adds a customer with given information.
removeCustomerById(int id) - Removes a customer with the given id.
ItemDAO
getAllItems() - Returns a list of all item objects in the database.
addItem(Item i) - Adds an item with given information.
removeItemById(int id) - Removes an item with the given id.
Create additional classes and attributes.
Knowledge Check
What is Design Pattern and why do we use it?
What is the Data Access Object (DAO) Pattern.
What are the Data Access Object Pattern components.
Summary
The Data Access Object (DAO) Pattern is now a widely accepted mechanism to abstract away the details of persistence in an application. The idea is that instead of having the domain logic, communicate directly with the database, file system, web service, or whatever persistence mechanism your application uses. The domain logic speaks to a DAO layer instead.
Every module (or group of routes example: /auth/<signup, login,etc.>) should have its own DAO layer.
Every module (or group of routes example: /auth/<signup, login,etc.>) should have its own set of models.
The DAO layer should use database queries as much as possible for various data manipulations.
Models should have their own getter and setter functions, which should be used by the Controller/DAO for data updation and retrieval.
Glossary/Terminology
DAO: Data Access Object
DTO: Data Transfer Object
DAL: Data: Access Layer
BLL: Business/controller Logic Layer
POJO: Plain Old Java Object
CRUD: Create, Read/Retrieve, Update and Delete
GOF: Gang of Four
References
Questions?
Last updated