chapter 37 l.
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 37 PowerPoint Presentation
Download Presentation
Chapter 37

Loading in 2 Seconds...

play fullscreen
1 / 37

Chapter 37 - PowerPoint PPT Presentation

  • Uploaded on

Chapter 37. Designing a Persistence Framework with Patterns. Persistent Objects. Storage mechanisms: Object databases Relational databases Other – flat files, XML structures, hierarchical databases, etc. Object-Relational (O-R) mapping service: maps an object to a relational record.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Chapter 37

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 37

Chapter 37

Designing a Persistence Framework with Patterns

persistent objects
Persistent Objects
  • Storage mechanisms:
    • Object databases
    • Relational databases
    • Other – flat files, XML structures, hierarchical databases, etc.
  • Object-Relational (O-R) mapping service: maps an object to a relational record.
persistence frameworks
Persistence Frameworks
  • Persistence framework: general-purpose, reusable, extendable set of types that provides functionality to support persistent objects.
    • Persistence service: subsystem created by persistence framework.
      • In technical services layer.
      • Called an O-R mapping service for RDB’s.
    • E.g., Hibernate for Java.
  • Transforming a non-object representation of data from a persistent store into objects.
    • Lazy materialization: an instance is only materialized on demand, when needed.
      • Implemented by a Virtual Proxy (sect. 37.18).
    • Caching: materialized objects are typically cached for performance.
  • Dematerialization (passivation):
    • The reverse transformation.
representing objects as tables
Representing Objects as Tables
  • Pattern: define a table in an RDB for each persistent object class.
    • Primitive object attributes map to columns.
    • Attributes that refer to other complex objects is more complicated.
object identifier pattern
Object Identifier Pattern
  • Assign an object identifier (OID) to each record and object (or proxy of an object).
    • Relates records to objects.
    • Avoids duplicates.
    • Usually alphanumeric value.
    • In object-land, represented by an OID interface or class.
    • In RDB, usually a fixed-length char value.
      • Every table has an OID as primary key.
      • Maps every object to some row in some table.
accessing a persistence service with a fa ade
Accessing a Persistence Service with a Façade
  • Façade provides a unified interface to a subsystem.
    • Operation to retrieve an object given OID.
      • Type of object to materialize is also needed.
    • Operation to store an object (dematerialize).
  • Façade delegates requests to subsystem objects.
database mapper pattern
Database Mapper Pattern
  • Direct mapping: persistent object class defines the code to save itself in a DB.
    • Strong coupling to persistent storage.
    • Reduced cohesion: technical services mixed with application logic.
  • Indirect mapping: create a class that is responsible for materialization, dematerialization and object caching.
    • Database Mapper or Database Broker.
    • Different mapper class for each persistent object class.
template method pattern gof
Template Method Pattern (GoF)
  • Define a method in a superclass that defines the skeleton of an algorithm, with its varying and unvarying parts.
    • Invokes other methods (“hook” methods), some of which may be overridden in a subclass to provide unique behavior at points of variability.
    • Template method is typically public, hook methods protected.
persistence framework for nextgen pos
Persistence Framework for NextGen POS
  • NextGen-specific classes are in a different package from general technical services Persistence package.
    • IMapper, AbstractPersistenceMapper, and AbstractRDBMapper are part of framework.
    • ProductDescriptionRDBMapper is a subclass added by application programmer.
    • ProductDescriptionInMemoryTestDataMapper produces hard-coded objects for testing without accessing an external DB.
guarded methods
Guarded Methods
  • AbstractPersistenceMapper.get method contains critical section.
    • The same object could be materializing concurrently on different threads.
    • Entire persistence subsystem may be distributed to a separate process on another computer.
      • PersistenceFacade as a remote server object.
      • Many threads running simultaneously, serving multiple clients.
configuring mappers with a mapper factory
Configuring Mappers with a Mapper Factory
  • A factory object MapperFactory can be used to configure the persistence façade with a set of IMapper objects.
    • Don’t name each mapper with a different operation, as in:

class MapperFactory


public IMapper getProductDescriptionMapper() {…}

public IMapper getSaleMapper() {…}


    • Instead, return a collection of mappers:

class MapperFactory

{ public Map getAllMappers() {…} }

data driven mapper instantiation
Data-driven Mapper Instantiation
  • The façade can then initialize its collection of IMappers with:

class PersistenceFacade


private java.util.Map mappers =



  • The factory can read system properties or use the reflective capabilities of the language (e.g., Java) to discover which IMapper classes to instantiate.
cache management
Cache Management
  • Pattern: Make the Database Mappers responsible for maintaining a local cache of materialized objects to improve performance.
    • When objects are materialized, they are cached, with their OID as key.
    • Subsequent requests to the mapper for an object will be satisfied from the cache if the object has already been materialized.
a class for sql statements
A Class for SQL Statements
  • Consolidate all SQL operations in a Pure Fabrication singleton.
    • SQL operations: SELECT, INSERT, . . .
    • RDB mapper classes collaborate with SQL-statements class to obtain a DB record or ResultSet (Java).
    • This is preferable to hard-coding SQL statements into the different RDB mapper classes.
example of a sql statements class
Example of a SQL-statements Class
  • Interface:

class RDBOperations


public ResultSet getProductDescriptionData(OID oid){…}

Public ResultSet getSaleData( OID oid ) { … }


  • Mapper:

class ProductDescriptionRDBMapper

extends AbstractPersistenceMapper

{ protected Object getObjectFromStorage( OID oid )

{ ResultSet rs = RDBOperations.getInstance().


ProductDescription ps = new ProductDescription();

ps.setPrice( rs.getDouble( “PRICE” ) );

ps.setOID( oid );

return ps;


transactional states and the state pattern
Transactional States and the State Pattern
  • Assume:
    • Persistent objects can be inserted, deleted, or modified.
    • Modifying a persistent object does not cause an immediate DB update – an explicit commit operation must be performed.
    • The response of an operation depends on the transactional state of the object:
      • An “old dirty” object was modified after retrieval.
      • An “old clean” object need not be updated in DB.
      • Delete or save causes state change, not commit.
fig 37 13 persistent object classes extend persistentobject
Fig. 37.13 Persistent object classes extend PersistentObject
  • PersistentObject provides common technical services for persistence
the state pattern gof
The State Pattern (GoF)
  • Problem: An object’s behavior is dependent on its state, and its methods contain case logic reflecting conditional state-dependent actions.
  • Solution: Create state classes for each state, implementing a common interface. Delegate state-depended operations from the context object to its current state obj.
    • Ensure the context object always points to a state object reflecting its current state.
database transactions
Database Transactions
  • Transaction: a unit of work whose tasks must all complete successfully or none must be completed.
    • Completion is atomic.
    • Represent the set of tasks to be done with a Transaction class.
    • The order of database tasks within a transaction can affect its success and performance.
      • Ordering database tasks can help: generally, inserts first, then updates, then deletes.
the command pattern gof
The Command Pattern (GoF)
  • Problem: How to handle requests or tasks that need functions such as prioritizing, queueing, delaying, logging, or undoing.
  • Solution: Make each task a class that implements a common interface.
    • Actions become objects that can be sorted, logged, queued, etc.
    • Each has a polymorphic execute method.
    • E.g., command objects can be kept in a history stack to enable “undo”.
lazy materialization with a virtual proxy
Lazy Materialization with a Virtual Proxy
  • Virtual Proxy (GoF): a proxy for another object (the real subject) that materializes the real subject when it is first referenced.
    • A lightweight object that stands for the real object that may or may not be materialized.
      • E.g., a Manufacturer object is rarely used, but a ProductDescription has attribute visibility to an IManufacturer instance.
      • When ProductDescription sends a getAddress message to the ManufacturerProxy, it materializes the real Manufacturer, using its OID.
representing relationships in tables
Representing Relationships in Tables
  • Representing Object Relationships as Tables pattern:
    • One-to-one associations
      • Place an OID foreign key in one or both tables representing the objects in a relationship, or treat as a one-to-many association, as below.
    • One-to-many associations (a collection) or many-to-many associations:
      • Create an associative table that records the OIDs of each object in relationship.