Chapter 38

Chapter 38

Persistence Framework with Patterns

1CS6359 Fall 2011 John Cole

Persistent Objects

• Object databases• Relational databases• Other: Flat files, XML, hierarchical databases,

etc.


Persistence Service

• A Persistence Framework is a general-purpose, reusable, and extendable set of types that provides functionality to support persistent objects.

• Also called an O-R Mapping service if it works with an RDB.


Frameworks

• A Framework is an extensible set of objects for related functions. For example Swing, or LINQ.

• Provides an implementation of core and unvarying functions and allows a programmer to plug in the varying functions or to extend them.


Frameworks

• Is a cohesive set of interfaces and classes to provide services for the core, unvarying part of a logical subsystem

• Contain concrete and abstract classes that define interfaces to conform to, object interactions to participate in, and other invariants

• Usually require the user to define subclasses of framework class to use, customize, and extend framework services


Frameworks

• Have abstract classes that may contain both abstract and concrete methods

• Rely on the Hollywood Principle: Don’t call us, we’ll call you. User-defined classes will receive messages from predefined framework classes

• Frameworks are reusable


Persistence Service and Framework

• Requirements:• Store and retrieve objects in a persistent

storage mechanism• Commit and rollback transactions• Extensible to support different storage

mechanisms


Key Ideas

• Mapping between a class and its persistent store and between object attributes and the fields in a record

• Object identity – to easily relate records to objects and ensure there are no inappropriate duplicates, records and objects have a unique identifier

• Database mapper – pure fabrication object responsible for materialization and dematerialization


Key Ideas

• Caches – persistence services cache materialized for performance

• Transaction state of object – State of objects in relation to the current transaction. Which objects are dirty?

• Transaction operations – Commit and Rollback


Key Ideas

• Lazy materialization – not all objects are materialized at once; materialization on demand

• Virtual proxies – Lazy materialization can be implemented using a smart reference known as a virtual proxy


Pattern: Representing Objects as Tables

• Define a table in the RDB for each persistent object class

• Attributes containing primitive data types map to columns

• Relational model requires that values be atomic (first normal form)


Pattern: Object Identifier

• Since it is desirable to have a consistent way to relate objects to records and no duplicate rows, use an Object Identifier for each record.

• Every table will have an OID as its key field and every record in the table will have a unique value for this key

• OID provides a consistent key type


Accessing Persistence Service with a Facade

• Define a façade for the various services• Retrieve an object given its OID; system needs

to know what kind of object, so provide the class type, too


Mapping Objects

• The Persistence Façade delegates the work• If a persistent object (such as

ProductDescription) persists itself, this is a direct mapping design

• This works if a compiler tool generates it• Problems: strong coupling of the object to

storage; complex responsibilities in an unrelated area.


Database Broker

• Class that is responsible for materialization, dematerialization, and object caching

• Pattern is also called Database Mapper• Define a different mapper class for each

persistent object


Mapper Factory

• Better not to name each mapper with a different operation. For example:

class MapperFactory{public IMapper getProductDescriptionMapper() {...}

public IMapper getSaleMapper() {...}...}


Mapper Factory

• Better:class PersistenceFacade

{

private java.util.Map mappers =

MapperFactory.getInstance().getAllMappers();

...

}


Metadata-based Mappers

• Instead of creating individual mapper classes for persistent types, these generate the mapping using metadata that describes the mapping

• Thus you can change the schema mapping in an external store and it will be reflected in the running system

• Pattern is Protected Variations WRT schema variations


Template Method Pattern

• Define a method (the Template Method) in a superclass that defines the skeleton of an algorithm. This invokes other methods, some of which may be overridden by a subclass

• Subclasses can override varying methods to provide unique behavior at points of variability


Template Pattern

• The basic algorithm structure is:• If the object is in cache, return it• If not, create it from its representation in

storage, save it in cache, and return it• The point of variation is how the object is

created from storage


Template Pattern

• Create the get method as the template in an abstract superclass AbstractPersistenceMapper that defines the template, and use a hook method in subclasses for the varying part.

• The get method contains critical section code that must be made thread-safe


Synchronized Methods in UML

• +get(OID): Object {guarded}

CS6359 Fall 2011 John Cole 22

Transactional States and the State Pattern

• Persistent objects can be inserted, deleted, or modified;

• Operating on a persistent object does not cause an immediate database update; an explicit commit operation must be done

• The response to an operation depends upon the transactional state of the object


Persistent Object Statechart


OldClean OldDirty

OldDelete

commit / delete

delete

New

[ from DB][new (not from DB)]

save

commit / update

delete

rollback / reload

rollback / reloadcommit / insert

State chart: PersistentObject

Legend:New--newly created; not in DBOld--retrieved from DBClean--unmodifiedDirty--modified

Deleted

PersistentObject

• Implements the following methods:– Commit()– Delete()– Rollback()– Save()

• Extending a domain class with a technical services class mixes architectural concerns


State Pattern

• Commit and Rollback have different logic but similar structure

• Problem: If an object’s behavior is dependent upon its state, is there an alternative to conditional logic?

• Solution: Create state classes for each state, implementing a common interface. Delegate state-dependent operations from the context object to its current state object. Ensure the context object always points to a state object reflecting its current state.


Transaction and the Command Pattern

• Transaction is a set of tasks that either must all be completed or none completed. Thus it is atomic

• The order of database tasks within a transaction can influence its success and performance


Transaction examples

• Suppose the database has a referential integrity constraint such that when a record is updated in table A that contains a foreign key reference to table B, the record in B must exist

• Suppose a transaction contains an INSERT task to add the B record and an update for A. If the update occurs before the insert, error

• Ordering the tasks helpsCS6359 Fall 2011 John Cole 28

Command Pattern

• Problem: How to handle requests or tasks that need functions such as sorting, queuing, delaying, logging, or undoing?

• Solution: Make each task a class that implements a common interface


Command Pattern

• Actions become objects and can be sorted, logged, etc.

• Each task or action is an object with an Execute method

• GUI actions such as cut and paste are examples of Command. The CutCommand’s execute method does a cut and its undo method reverses the cut. These objects can be stacked


Lazy Materialization with a Virtual Proxy

• Sometimes useful not to materialize an object until absolutely necessary. This may be because the object is rarely referenced.

• Example: Manufacturer object referenced by ProductDescription

• Virtual Proxy gets the real object on first reference, thus standing in for the object.

• Created by the object that references the other object


Representing Relationships

• One-to-one: place an OID foreign key in one or both tables or create an associative table with the OIDs of each object in the relationship.

• One-to-many: Create an associative table with keys of both objects

• Many-to-many: Create an associative table with keys of both objects


Separation of Concerns

• Weakness of creating a PersistentObject class but it couples domain classes to technical services classes

• Separation is not an absolute rule, but be careful how you break it


Documents

Chapter 38