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.
|
Copyright (c) 2002
nakedobjects.org You may print this document for your own personal
use, or you may copy it in electronic form for access within your
organisation, provided this notice is preserved.
|
previous | contents | next
|