1 / 33

Chapter 38

Chapter 38. Persistence Framework with Patterns. Persistent Objects. Object databases Relational databases Other: Flat files, XML, hierarchical databases, etc. Persistence Service.

zaza
Download Presentation

Chapter 38

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  22. Synchronized Methods in UML • +get(OID): Object {guarded} CS6359 Fall 2011 John Cole

  23. 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 Cole

  24. Persistent Object Statechart CS6359 Fall 2011 John Cole

  25. 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 Cole

  26. 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 Cole

  27. 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 Cole

  28. 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 Cole

  29. 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 Cole

  30. 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 Cole

  31. 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 Cole

  32. 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 Cole

  33. 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 Cole

More Related