Designing a Persistence Framework with Patterns

1
Chapter 37

• Designing a Persistence Framework with Patterns

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

3
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 RDBs.
• E.g., Hibernate for Java.

4
Materialization

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

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

6
Fig. 37.1 Mapping objects and tables
7
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.

8
Fig. 37.3 OIDs link objects and records
9
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.

10
Fig. 37.4 The Persistence Façade
11
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.

12
Fig. 37.5 Database Mappers
13
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.

14
Fig. 37.6 Template Method pattern in GUI
framework
15
Fig. 37.7 Template Method for mapper objects
16
Fig. 37.8 Overriding the hook method
17
Fig. 37.9 Template Method twice to factor common
code for RDB
18
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.

19
Fig. 37.10 The persistence framework
20
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.

21
Fig. 37.11 Guarded methods in the UML
22
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.
• Dont 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()

23
Data-driven Mapper Instantiation

• The façade can then initialize its collection of
  IMappers with
• class PersistenceFacade
• private java.util.Map mappers
• MapperFactory.getInstance().getAllMappers()
• The factory can read system properties or use the
  reflective capabilities of the language (e.g.,
  Java) to discover which IMapper classes to
  instantiate.

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

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

26
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().
• getProductDescriptionData(o
  id)
• ProductDescription ps new
  ProductDescription()
• ps.setPrice( rs.getDouble( PRICE ) )
• ps.setOID( oid )
• return ps

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

28
Fig. 37.12 Statechart for PersistentObject
29
Fig. 37.13 Persistent object classes extend
PersistentObject

• PersistentObject provides common technical
  services for persistence

30
The State Pattern (GoF)

• Problem An objects 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.

31
Fig. 37.14 Applying the State pattern
32
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.

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

34
Fig. 37.15 Commands for database operations
35
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.

36
Fig. 37.16 Manufacturer Virtual Proxy
37
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.