Jdbc Lecture5
Upcoming SlideShare
Loading in...5
×
 

Jdbc Lecture5

on

  • 951 views

 

Statistics

Views

Total Views
951
Views on SlideShare
950
Embed Views
1

Actions

Likes
0
Downloads
22
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Jdbc Lecture5 Jdbc Lecture5 Presentation Transcript

  • 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
  • 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 Helper Composite View Business Delegate Session Façade Value Object Assembler Data Access Object Value Object Service 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.
    • 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.
  • 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.
  • 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.
  • 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)
  • 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 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)
  • 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 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.
  • 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 Relational Database JDBC MemberDAO Java Data Object JDO MemberDAO SOAP envelope Web Service MemberDAO XML (Xindice) XPath