Chapter 38 Persistence Framework with Patterns 1CS6359 Fall 2011 John Cole

Persistent Objects Object databases Relational databases Other: Flat files, XML, hierarchical databases, etc. 2CS6359 Fall 2011 John Cole

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. 3CS6359 Fall 2012 John Cole

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. 4CS6359 Fall 2011 John Cole

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 5CS6359 Fall 2011 John Cole

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 6CS6359 Fall 2011 John Cole

Persistence Service and Framework Requirements: Store and retrieve objects in a persistent storage mechanism Commit and rollback transactions Extensible to support different storage mechanisms 7CS6359 Fall 2011 John Cole

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 8CS6359 Fall 2011 John Cole

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 9CS6359 Fall 2011 John Cole

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 10CS6359 Fall 2011 John Cole

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) 11CS6359 Fall 2011 John Cole

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 12CS6359 Fall 2011 John Cole

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 13CS6359 Fall 2011 John Cole

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. 14CS6359 Fall 2011 John Cole

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 15CS6359 Fall 2011 John Cole

Mapper Factory Better not to name each mapper with a different operation. For example: class MapperFactory { public IMapper getProductDescriptionMapper() {...} public IMapper getSaleMapper() {...}... } 16CS6359 Fall 2011 John Cole

Mapper Factory Better: class PersistenceFacade { private java.util.Map mappers = MapperFactory.getInstance().getAllMappers();... } 17CS6359 Fall 2011 John Cole

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 18CS6359 Fall 2011 John Cole

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 19CS6359 Fall 2011 John Cole

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 20CS6359 Fall 2011 John Cole

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 21CS6359 Fall 2011 John Cole

Synchronized Methods in UML +get(OID): Object {guarded} CS6359 Fall 2011 John Cole22

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 CS6359 Fall 2011 John Cole23

Persistent Object Statechart CS6359 Fall 2011 John Cole24

PersistentObject Implements the following methods: – Commit() – Delete() – Rollback() – Save() Extending a domain class with a technical services class mixes architectural concerns CS6359 Fall 2011 John Cole25

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. CS6359 Fall 2011 John Cole26

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 CS6359 Fall 2011 John Cole27

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 helps CS6359 Fall 2011 John Cole28

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 CS6359 Fall 2011 John Cole29

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 CS6359 Fall 2011 John Cole30

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 CS6359 Fall 2011 John Cole31

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 CS6359 Fall 2011 John Cole32

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 CS6359 Fall 2011 John Cole33