Chapter 37 l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

Chapter 37 PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on
  • Presentation posted in: General

Chapter 37. Designing a Persistence Framework with Patterns. 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.

Download Presentation

Chapter 37

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Chapter 37 l.jpg

Chapter 37

Designing a Persistence Framework with Patterns


Persistent objects l.jpg

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.


Persistence frameworks l.jpg

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.


Materialization l.jpg

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.


Representing objects as tables l.jpg

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.


Fig 37 1 mapping objects and tables l.jpg

Fig. 37.1 Mapping objects and tables


Object identifier pattern l.jpg

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.


Fig 37 3 oids link objects and records l.jpg

Fig. 37.3 OIDs link objects and records


Accessing a persistence service with a fa ade l.jpg

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.


Fig 37 4 the persistence fa ade l.jpg

Fig. 37.4 The Persistence Façade


Database mapper pattern l.jpg

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.


Fig 37 5 database mappers l.jpg

Fig. 37.5 Database Mappers


Template method pattern gof l.jpg

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.


Fig 37 6 template method pattern in gui framework l.jpg

Fig. 37.6 Template Method pattern in GUI framework


Fig 37 7 template method for mapper objects l.jpg

Fig. 37.7 Template Method for mapper objects


Fig 37 8 overriding the hook method l.jpg

Fig. 37.8 Overriding the hook method


Fig 37 9 template method twice to factor common code for rdb l.jpg

Fig. 37.9 Template Method twice to factor common code for RDB


Persistence framework for nextgen pos l.jpg

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.


Fig 37 10 the persistence framework l.jpg

Fig. 37.10 The persistence framework


Guarded methods l.jpg

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.


Fig 37 11 guarded methods in the uml l.jpg

Fig. 37.11 Guarded methods in the UML


Configuring mappers with a mapper factory l.jpg

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() {…} }


Data driven mapper instantiation l.jpg

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.


Cache management l.jpg

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.


A class for sql statements l.jpg

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.


Example of a sql statements class l.jpg

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;

    }


Transactional states and the state pattern l.jpg

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.


Fig 37 12 statechart for persistentobject l.jpg

Fig. 37.12 Statechart for PersistentObject


Fig 37 13 persistent object classes extend persistentobject l.jpg

Fig. 37.13 Persistent object classes extend PersistentObject

  • PersistentObject provides common technical services for persistence


The state pattern gof l.jpg

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.


Fig 37 14 applying the state pattern l.jpg

Fig. 37.14 Applying the State pattern


Database transactions l.jpg

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.


The command pattern gof l.jpg

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”.


Fig 37 15 commands for database operations l.jpg

Fig. 37.15 Commands for database operations


Lazy materialization with a virtual proxy l.jpg

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.


Fig 37 16 manufacturer virtual proxy l.jpg

Fig. 37.16 Manufacturer Virtual Proxy


Representing relationships in tables l.jpg

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.


  • Login