BTS530: Major Project Planning and Design

1. BTS530: Major Project Planning and Design Patterns for a Persistence Framework References and Material From: Applying UML and Patterns, 3rd Edition, chapter 38

2. Agenda • Persistence & Frameworks • Object Retrieval and Storage • Pattern: Representing Objects as Tables • Pattern: Object Identifier • Accessing a Persistence Service • Pattern: (Persistence) Facade • Pattern: Database Mapper

3. Persistence • Excellent (open source) persistence frameworks are available • In BTS530 we use this as an introduction to framework design and an aid to understanding persistence mapping • http://www.onjava.com/pub/a/onjava/2004/04/07/wiringwebapps.html

4. Persistent Objects • require persistent storage (e.g. Product) • storage mechanisms include • object db (rare) • relational db • other, e.g. flat files, XML structures etc. • problem in most cases is mismatch between objects and non-OO formats

5. Persistence Framework • general purpose, reusable, extendable set of types providing the functionality to support persistent objects • offers a persistent service, usually written to work with RDB’s • must translate objects into records (or other structure) and save them in a db • must translate records into objects when retrieving from db

6. Frameworks in General • cohesive set of interfaces and classes collaborating to provide services for the core, unvarying part of a logical subsystem • … p. 627 • user defined classes will receive messages from the predefined framework classes (usually this means implementing superclass abstract methods) • reusable! • e.g. Java Swing Framework

7. Persistence Framework • Should provide functions to • store and retrieve objects in a persistent storage mechanism (db) • “commit” and “rollback” transactions • Should be extendable to support different mechanisms and formats e.g. RDBs, flat files, XML in files

8. Object Retrieval & Storage • There must be a mapping between a class and its persistent store (schema mapping) e.g. :Product object to a row in the Product table. • Records and objects must have a unique identifier to prevent inappropriate duplicates and facilitate relation of records to objects • Database Mapper (a pattern!) is a pure fabrication object responsible for: • Materialization: transform non-object representation to object (e.g. record in db to object) • Dematerialization: the opposite

9. Pattern: Representing Objects As Tables (ROAT) • How do you map an object to a record or a RDB schema? • ROAT: • define a table in a RDB for each persistent object class. Object attributes for primitive data types map to columns. • note: things become less straightforward when objects have attributes that refer to other complex objects

10. Fig. 38.1, p629 Class Object Table

11. Pattern: Object Identifier • How do you relate objects to records in a consistent manner while ensuring repeated materialization does not result in duplicate objects? • Object Identifier Pattern • assign an object identifier (OID) to each record and object • OID is typically alphanumeric; generated in various ways (see p.630); can be unique to one DB, to globally unique, etc.

12. Object Identifier • In an object OID represented by an OID interface or a class that encapsulates the actual value and its representation • In a RDB, usually stored as char value • Each table has OID as primary key, and each object will have an OID (directly or indirectly) • =>every object can be uniquely mapped to a row in a table

13. Object Identifier Fig. 38.3, p. 631

14. Accessing A Persistence Svc. • Define a “persistence façade” • needs an operation to retrieve an object given a OID • needs to know type of object Fig. 38.4, p. 631

15. Pattern: Database Mapper • The persistence façade does not do the work itself but delegates to subsystem objects. • who should be responsible for the materialization/dematerialization of objects from a persistent store? (Why not the persistent object class itself?) • Database Mapper • a different mapper class is defined for each persistent object class

16. Database Mapper Fig. 38.5, p. 633

17. Mapper Factory • How do you configure the PersistenceFacade with a set of IMapper objects? • Mapper Factory • NB: not desireable to name each mapper with a different operation

18. Mapper Factory • The following does NOT support Protected Variations with respect to a growing list of mappers: class MapperFactory { public Imapper getProductDescriptionMapper() {…} public Imapper getSaleMapper() {…} … } (p. 640)

19. Mapper Factory • Better class MapperFactory { public Map getAllMappers() {…} … } • the façade can initialize its Mapper collection as follows: class PersistenceFacade { private java.util.Map mappers = MapperFactory.getInstance().getAllMappers(); … } where the java.util.Map keys are the Class objects (persistent types) and the IMappers are the values the factory can assign a set of Imappers using a data-driven design (ie. read system properties to see which Imapper classes to instantiate)