The document discusses various data access patterns used in Java applications, including the Data Access Object (DAO) pattern, Value Object (VO) pattern, and handling data access exceptions. It describes using DAO interfaces to abstract data access logic and database details. Value objects wrap database rows to allow working with business objects. The document provides examples of implementing these patterns for a sample application.

1. JDBC Session 5 Tonight: Data Access Patterns J2EE Architecture & Design Patterns The Data Access Tier Data Access Patterns DataAccessObject (DAO) Value Object Pattern (VO) DataAccessException Designing a Framework

2. 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)

3. 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

4. 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)

5. 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)

6. 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 Helper Composite View Business Delegate Session Façade Value Object Assembler Data Access Object Value Object Service Locator

7. 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. Front controller takes incoming user request and decides what to do with it. Business delegate is the business logic responsible for processing the user’s request. View helpers are responsible for rendering the output that is sent back to the end user.

8. JDBC Session 5 The Business Layer J2EE Architecture & Design Patterns (p. 7) Business Delegate Session Facade Business Objects 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. A session façade wraps the individual classes that carry out an entire business process. The business objects are fine-grained objects used in carrying out the process. Session Facade Session Facade 1. 2. 3.

9. JDBC Session 5 The Data Access Layer J2EE Architecture & Design Patterns (p. 8) Data Access Object Data Access Object Data Access Object Value Objects A business object will retrieve and manipulate data using a Data Access Object. (DAO) A DAO will encapsulate all of the CRUD logic (Create, Replace, Update, Delete) in the application. All data sent to a DAO or retrieved from a DAO will be encapsulated in a Value Object (VO) 1. 2. 3.

10. 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)

11. 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)

12. 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)

13. 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)

14. 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)

15. 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)

16. 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)

17. 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)

18. 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 deleteFlag At 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)

19. 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)

20. 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)

21. JDBC Session 5 Example on Web Site: Lessons / JDBC / JDBC Session 5 / DataAccessExample Finally an Example!

22. JDBC Session 5 For 1000 no-points: What other example have we looked at that kinda uses this pattern? Test Question

23. JDBC Session 5 Designing a Framework (p. 1) 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.

24. 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)

25. JDBC Session 5 DAO’s: Not just about Relational Databases: Designing a Framework (p. 3) MemberDAO Relational Database JDBC MemberDAO Java Data Object JDO MemberDAO SOAP envelope Web Service MemberDAO XML (Xindice) XPath