JDBC Session 5

Tonight: Data Access Patterns

1. J2EE Architecture & Design Patterns

2. The Data Access Tier

3. Data Access Patterns– DataAccessObject (DAO)– Value Object Pattern (VO)– DataAccessException

4. Designing a Framework

JDBC Session 5

What are J2EE Design Patterns?

• J2EE Design Patterns are specifically geared towards J2EE and Web Application Development.

• These patterns focus on properly partitioning an application into distinct layers.

• This makes it easier to maintain the application and gives more flexibility in distributing the application among different physical locations.

J2EE Architecture & Design Patterns (p. 1)

JDBC Session 5

Partitioning a Web Application

J2EE Architecture & Design Patterns (p. 2)

Presentation Tier

Business Tier (a.k.a The Middle Tier)

Data Tier

Corporate Database Corporate Database

JDBC Session 5

What Each Tier Does• Presentation Tier

– Renders screens the user will see and interact with. For a Java web application the presentation tier consists of JSP or servlet code that generates HTML for the end user to see.

• Business Logic Tier– Enforces the application’s business rules.

• Data Access Tier– Carries out all data source tasks (CRUD Tasks).

J2EE Architecture & Design Patterns (p. 3)

JDBC Session 5

Why Partition the Application into Tiers • Makes the application easier to maintain. Each tier in an

application is unaware of the implementation details of any of the other tiers.

• Enforces a layered, closed architecture where each tier can only speak to the tier below it.

• Even when speaking to the tier below it, the upper tier only speaks through well-defined interfaces to the lower tiers. We try never to expose the upper tier to any implementation details of the lower tier.

• Tiers are a logical division of labor and do not necessarily denote that the application has to be physically separated onto three distinct pieces of hardware.

J2EE Architecture & Design Patterns (p. 4)

JDBC Session 5

Categories of J2EE Design Patterns

J2EE Architecture & Design Patterns (p. 5)

Presentation Tier Patterns

Business Tier Patterns

Integration Tier/Data Access Tier Patterns

Intercepting Filter Front Controller View HelperComposite View

Business DelegateSession FaçadeValue Object Assembler

Data Access ObjectValue ObjectService Locator

JDBC Session 5

Typical J2EE Design Patterns Implementation

J2EE Architecture & Design Patterns (p. 6)

Front Controller

Business Delegate

View Helper Integration/Data Access Tier

1.

2.

3.

1. Front controller takes incoming user request and decides what to do with it.

2. Business delegate is the business logic responsible for processing the user’s request.

3. View helpers are responsible for rendering the output that is sent back to the end user.

JDBC Session 5

The Business Layer

J2EE Architecture & Design Patterns (p. 7)

Business Delegate

Session Facade

Business Objects

1. A business delegate hides the mechanics of how a process is invoked. The developer using the delegate does not know if they are using an EJB or a web service.

2. A session façade wraps the individual classes that carry out an entire business process.

3. The business objects are fine-grainedobjects used in carrying out the process.

Session Facade

Session Facade

1.

2.

3.

JDBC Session 5

The Data Access Layer

J2EE Architecture & Design Patterns (p. 8)

Data AccessObject

Data AccessObject

Data AccessObject

Value Objects

1. A business object will retrieve and manipulate data using a Data Access Object. (DAO)

2. A DAO will encapsulate all of the CRUD logic (Create, Replace, Update, Delete) in the application.

3. All data sent to a DAO or retrieved from a DAO will be encapsulated in a Value Object (VO)

1.

2.

3.

JDBC Session 5

Why Focus on the Data Access Layer?• Most organizations spend a significant amount of time modeling

their business logic and presentation tiers.• However the data access tier is often left as an after thought.

Most developers do not see the long-term benefits of a well-defined data access tier.

• JDBC code when not used properly can wreak havoc on the long-term maintainability of a system.

• Failure to clearly separate the data access layer into a well-defined set of interfaces creates tight dependencies in:– The business objects consuming the data in the database. Change the

structure or relationships in your database and you have to change your applications.

– Exposes your applications to vendor specific database extensions that make it difficult to port your applications to another platform.

The Data Access Tier (p. 1)

JDBC Session 5

The Solution to “Data Madness”

• Apply common J2EE Data Access Patterns that will allow us to hide all JDBC access code behind a well-defined layer.

• Provide an OO-based set of objects for manipulating relational data (Object-Relational mapping).

• Have a clearly defined data persistence framework that:– Encourages a clean separation of data-persistence logic from presentation

and business logic.– Decouples the application(s) built on the framework from having any

knowledge of the database platform the data is residing in.– Abstracts away the physical details of how data is stored within a

database and also the relationships that exist between entities in the database.

– Simplifies the development process by hiding the details associated with getting a database connection, issuing a command and managing transactions.

The Data Access Tier (p. 2)

JDBC Session 5

The three patterns we’ll study in this lesson are:

• Data Access Object Pattern (DAO)

• Value Object Pattern (VO)

• DataAccessException

Data Access Patterns (p. 1)

JDBC Session 5

Here’s a class diagram of the architecture:

• The DataAccessObject (DAO) is the primary mechanism for retrieving and manipulating data from the data base.

• The ValueObject (VO) wraps data retrieved from a relational database in a Java object.

Data Access Patterns (p. 2)

JDBC Session 5

The Data Access Object consists of an Interface called DataAccessObject.java

The two functions of the DAO Pattern:

• Completely abstract away the data source in which the data the user is requesting resides.

• Completely abstracts away all of the CRUD (Create, Replace, Update, Delete) logic normally associated with accessing a data source.

DataAccessObject (p. 1)

JDBC Session 5

The DAO pattern abstracts away the tasks associated with retrieving and manipulating data by defining a Java interface that has 5 basic methods:

• findByPrimaryKey( Object pPrimaryKey )• createValueObject()• insert( ValueObject pValueObject )• update( ValueObject pValueObject )• delete( ValueObject pValueObject )

DataAccessObject (p. 2)

JDBC Session 5

Remember, DataAccessObject.java is an interface, so to use it we define one or more member classes that implement the interface:

DataAccessObject (p. 3)

+findByPrimaryKey(in primaryKey : String, ) : ValueObject+insert(in values : ValueObject)+update(in values : ValueObject)+delete(in values : ValueObject)

«interface»DataAccessObject

MemberDAO

JDBC Session 5

The Value Object consists of an abstract class called ValueObject.java

A Value Object Pattern wraps a row of data retrieved from a data source in a Plain Old Java (POJ) class:

• This lets the user deal with a logical view of the data instead of a physical view.– Value objects hide the data types of the data being retrieved.– Value objects hide the relationships that exist between tables

in the database.• Value objects are the glue that ties the tiers together. They are

used to pass data back and forth between all tiers in the application.

ValueObject (p. 1)

JDBC Session 5

The VO class has 3 status fields with their own get() and set() methods that are used to tell the DAO what to do with the VO:

• boolean insertFlag• boolean updateFlag• boolean deleteFlagAt any given time, only 1 of the flags may be true. Setting any one

of the flags resets the others to false. The VO class also provides a reset() method that clears all flags to false.

Finally, the VO class provides get() and set() methods for a rowVersion field. long rowVersion is used to implement the framework’s locking strategy.

ValueObject (p. 2)

JDBC Session 5

Remember, ValueObject.java is abstract, so to use it we define one or more member classes that extend the VO:

ValueObject (p. 3)

JDBC Session 5

• Never allow data access specific exceptions to be thrown from the data access objects.

• Capture all exceptions thrown and re-throw them under a generic data access tier.

• The data access tier should be responsible for logging and handling all errors thrown from it.

DataAccessException (p. 1)

JDBC Session 5

Example on Web Site:

• Lessons / JDBC / JDBC Session 5 / DataAccessExample

Finally an Example!

JDBC Session 5

For 1000 no-points:

• What other example have we looked at that kinda uses this pattern?

Test Question

JDBC Session 5Designing a Framework (p. 1)

Framework Package

businessdelegate

valueobject

dataaccess

sessionfacade

• Layout your framework structure immediately. It’s very difficult to refactor out packages later on.

• Keep the structure simple.

• Centralize responsibility for the code in one team. Remember this code is supposed to be shared across applications.

JDBC Session 5

• In the enterprise, applications come and go, but the data in these systems lives on.

• A persistence framework defines a standard set of interfaces for retrieving and manipulating data. Code re-use often comes from interface re-use.

• A well-defined data access tier is often times one of the most re-used pieces of code within the enterprise.

• Stick to your implementation. Do not let time constraints compromise the integrity of your architecture.

• Architecture and J2EE Pattern Usage has to have a business case. Using patterns for the sake of patterns is self-destructive.

Designing a Framework (p. 2)

JDBC Session 5

DAO’s: Not just about Relational Databases:

Designing a Framework (p. 3)

MemberDAO

RelationalDatabase

JDBC

MemberDAO

Java DataObject

JDO

MemberDAO

SOAPenvelope

Web Service

MemberDAO

XML(Xindice)

XPath