1. DESIGNING A PERSISTENCE FRAMEWORK WITH PATTERNS

2. The Problem: Persistent Objects persistent object An object that can survive the process or thread that created it. A persistent object exists until it is explicitly deleted ProductDescription Storage Mechanisms and Persistent Objects Object databases Relational databases others

3. The Solution: A Persistence Service from a Persistence Framework The framework should provide functions such as: store and retrieve objects in a persistent storage mechanism commit and rollback transactions

4. persistence framework general-purpose, reusable, and extendable set of types that provides functionality to support persistent objects framework A set of collaborating abstract and concrete classes that may be used as a template to solve a related family of problems. It is usually extended via subclassing for application-specific behavior

5. Key Ideas Mapping Object identity Database mapper Materialization and dematerialization Caches Transaction state of object Transaction operations Lazy materialization Virtual proxies

6. The Representing Objects as Tables pattern How do you map an object to a record or relational database schema? The Representing Objects as Tables pattern

8. UML Data Modeling Profile «Table» ProductDescription «PK» OID:char(16) Description:varchar(100)... «FK» Manu_OID:char(16) «Table» Manufacturer «PK» OID:char(16) Name:varchar(100) City:varchar(50) * 1 aggregate signifies a referential constraint:a ProductDescription row can't exist without a related Manufacturer row PK-primary key FK-foreign key

10. 对关系的存储设计

16. 对泛化的存储设计

17. Method 1

18. Method 2a

21. Method 2b

23. object identifier (OID)pattern

24. Accessing a Persistence Service with a Facade

25. Mapping Objects: Database Mapper or Database Broker Pattern Who should be responsible for materialization and dematerialization of objects (for example, a ProductDescription) from a persistent store?

26. The PersistenceFacade — as true of all facades — does not do the work itself, but delegates requests to subsystem objects. direct mapping persistent object class itself indirect mapping Database Broker pattern Database Mapper pattern

27. Metadata-Based Mappers class PersistenceFacade { / /... public Object get( OID oid, Class persistenceClass ) { // an IMapper is keyed by the Class of the persistent object IMapper mapper = (IMapper) mappers.get( persistenceClass ); // delegate return mapper.get( oid ); } //... } usage: (Manufacturer) PersistenceFacade.getInstance(). get( manuOID, Manufacturer.class) );

30. Template Method Pattern

31. Framework Design with the Template Method Pattern if (object in cache) return it else create the object from its representation in storage save object in cache return it

33. How to use the Framework

35. Further factoring out the varying and unvarying parts of the algorithm.

37. Final Framework

40. Configuring Mappers class MapperFactory { public IMapper getProductSpecificationMapper(){...} public IMapper getSaleMapper() {...} }

41. class MapperFactory{ public Map getAllMappers( ) {...} } class PersistenceFacade{ private java.util.Map mappers = MapperFactory.getlnstance( ).getAllMappers( ); }

43. class ProductSpecificationRDBMapper extends … { // hook method override protected Object getObjectFromStorage( OID oid ) { String key = oid.toString(); dbRec = SQL execution result of: "Select * from PROD_SPEC where key =" + key ProductSpecification ps = new ProductSpecification(); ps.setOID( oid ); ps.setPrice( dbRec.getColumn("PRICE") ); ps.setItemID( dbRec.getColumn("ITEM_ID") ); ps.setDescrip( dbRec.getColumn("DESC") ); return ps; }

44. class RDBOperations { public ResultSet getProductDescriptionData( OID oid ) {...} public ResultSet getSaleData( OID oid ) {...}... } 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; }

46. Pattern: Cache Management to maintain materialized objects in a local cache to improve performance (materialization is relatively slow) and support transaction management operations such as a commit. When objects are materialized, they are placed in the cache, with their OID as the key. Subsequent requests to the mapper for an object will cause the mapper to first search the cache, thus avoiding unnecessary materialization

47. Transactional States and the State Pattern Persistent objects can be inserted, deleted, or modified. Operating on a persistent object (for example, modifying it) does not cause an immediate database update; rather, an explicit commit operation must be performed.

48. OldCleanOldDirty OldDelete commit/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 DB Old--retrieved from DB Clean--unmodified Dirty--modified Deleted

51. GoF State pattern Context/Problem An object's behavior is dependent on its state, and its methods contain case logic reflecting conditional state-dependent actions. 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.

54. Designing a Transaction with the Command Pattern

55. Ordering the database tasks Table A: caseNo StudentNo Health Table B: StudentNo StudentName Inseart a record ( “ 05001 ”, ” wang ” ) to B update A ("001","05001"),

56. Command Context/Problem How to handle requests or tasks that need functions such as sorting (prioritizing), queueing, delaying, logging, or undoing? Solution Make each task a class that implements a common interface

57. actions become objects, and thus can be sorted, logged, queued, and so forth.

59. Lazy Materialization with a Virtual Proxy

61. // EAGER MATERIALIZATION OF MANUFACTURER class ProductSpecificationRDBMapper extends AbstractPersistenceMapper{ protected Object getObjectFromStorage( OID oid ){ ResultSet rs = RDBOperations.getlnstance().getProductSpecificationData( oid ); ProductSpecification ps = new ProductSpecification(); ps.setPrice( rs.getDouble( "PRICE" ) ); // here's the essence of it String manufacturerForeignKey = rs.getString( "MANU_OID" ); OID manuOID = new OID( manufacturerForeignKey ); ps.setManufacturer( (Manufacturer) PersistenceFacade.getInstance(). get(manuOID, Manufacturer.class) ); // or LAZY MATERIALIZATION OF MANUFACTURER ps.setManufacturer( new ManufacturerProxy( manuOID ) );

62. the Representing Object Relationships as Tables one-to-one associations Place an OID foreign key in one or both tables representing the objects in relationship. Or, create an associative table that records the OIDs of each object in relationship.

63. one-to-many associations, such as a collection many-to-many associations Create an associative table that records the OIDs of each object in relationship.

64. Unresolved Issues dematerializing objects Briefly, the mappers must define putObjectToStorage. methods. Dematerializing composition hierarchies requires collaboration between multiple mappers and the maintenance of associative tables (if an RDB is used). materialization and dematerialization of collections queries for groups of objects thorough transaction handling error handling when a database operation fails multiuser access and locking strategies security — controlling access to the database