Mementos and Delegates
One of the key features of a solid persistence architecture is a separation of business logic from persistence logic. This separation is critical for these reasons:
The skill set required for writing business components is very different from that required for database programming. By separating different kinds of behavior in various components, different people can easily “own” the development and maintenance of those components.
If a business component is independent of the persistence logic, it requires no changes should the persistence logic change; even if that change involves a migration to a new database engine or even a new persistence mechanism.
You will use two key
design patterns to support the
separation of business logic from persistence logic: the
memento
pattern and delegation.
BaseEntity
specifically delegates its
implementation of the Persistent
interface in
Example 9.2 to a specialized persistence component.
This sample code shows how that delegation works:
public final void store(Transaction trans) throws StoreException { Memento mem = new Memento(this); if( !isValid ) { throw new StoreException("This object is no longer valid."); } handler.store(trans, mem); }
The BaseEntity
class references an attribute
called handler
that is an instance of a class
implementing the
PersistenceSupport
interface. This object is called the
delegate. It supports
the persistence operations for an entity. Each method delegated to it
requires a Transaction
object ...
Get Database Programming with JDBC & Java, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.