Naked Objects - Making naked objects persistent

Naked Objects
By Richard Pawson and Robert Matthews

Building a multi-user system

Making naked objects persistent

Naked objects are made persistent though an object store, which normally interfaces with a persistence mechanism such as a database. Any class that implements the org.nakedobjects.object.NakedObjectStore interface can serve as an object store. At the time of writing, five alternative object stores are available (either as part of the framework or downloaded from our website) together with documentation on how to use them:

XML Object Store This stores each naked object instance as a separate file in XML format. This is currently only suitable for use during prototyping, when dealing with small numbers of instances. It has the advantage that the file formats can eaily be read by the programmer as well as other tools. It is also reasonably robust to changes in the object definitions during prototyping - you can usually add or delete fields without having to change the existing data files.
Serialized Object Store This stores each instance as a separate file, using Java's serialization. It is only suited to prototyping or to applications with small volumes of data. However, it is more efficient than the XML store, especially for complex objects.
SQL Object Store This will work with any JDBC-compliant relational database and is suitable for many business applications. If you are developing a new and straightforward application, then the SQL Object Store can manage the whole process of setting up the database and creating the necessary tables transparently: the programmer can simply define the business objects assuming that they will be stored and retrieved from a relational database as needed. If the application must use existing relational tables, or store its objects in a known fashion for access by other applications, then a programmer can manually specify a series of mapping objects. Manually-specified mappings may also be necessary on very large or complex applications, for performance reasons.
EJB Object Store This object store was written by Dave Slaughter of Safeway, and allows a Naked Objects application to take advantage of the capabilities of Enterprise Java Beans. EJBs provide very good support for scaleability, transactions and security. Using this object store, Naked Objects can interoperate with other systems built on an EJB infrastructure.
Transient Object Store This provides the functionality of an object store (which is required by the framework so it can run) but without persistence, i.e. the states of the objects are only maintained while the application is running and are not saved between framework invocations. This is an integral part of the framework and is used by default when running an org.nakedobjects.Exploration application. This allows object definitions to be changed easily when initially crafting the naked objects. It is also convenient for testing as there are no unexpected objects in existence when the test application is started.

We expect that over time many more object stores will be made available for Naked Objects, as well as improved versions of the existing ones.

When the framework is run as a server it uses the persistent object store that is specified in the configuration file. Unless you need custom mappings, it is possible to swap the object store just by editing one line of that file - no changes need to be made to the coding of the naked objects themselves. The default configuration file supplied as part of the distribution specifies the XML Object Store.

As a developer there are thus three ways that you can use an object store:

You can specify an existing object store and use it transparently.
You can specify an existing object store and provide your own mappings or other forms of custom control over persistence.
You can write a new object store, usually as a wrapper for an existing database or other persistence mechanism. (The requirements for an object store are detailed in the framework API and discussed on our website.)

The framework supports the philosophy that any change that a user makes to any object, whether by directly changing its attributes or associations, or by invoking an action method, is immediately made persistent. For this reason the naked objects in our examples do not have explicit 'save' or 'make persistent' actions. This is a deliberate design choice. The design of the Naked Objects framework means that it is possible to take this approach for many applications and still achieve desirable performance levels. The immediacy is also consistent with the expressive style of systems that Naked Objects produces.

It is possible to delay the process of making an object persistent by creating transient objects and subsequently making them persistent. For example, an order object could be created and prepared ensuring that all items are available before adding the object to the object store. Unfortunately though, once the object has been made persistent any further changes made to that object will be persisted as soon they are made.

In a future release the framework will also support the explicit saving of objects, where this may be necessary for performance or other reasons.