Database Programming with JDBC & Java, Second Edition

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