Chapter 37

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 RDB’s. • 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. • 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() {…} }

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(oid); 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 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.

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.