Issues in Persistence

The application programmer is typically concerned with the business logic that must be developed to implement the processing involved in a use case. Adding persistence to the objects that implement this logic (business objects) engenders a number of issues:

Each element of an object's structure (attribute, association, hierarchy) must be mapped to an element of the persistent storage.
The application source code must include saving, updating and retrieving business objects to and from the persistent store. This code must be written and tested for a specific persistence mechanism.
The format of the persistent store must be kept in "synch" with the definitions of the objects that are kept in that store. During the development process, the definition of an object will change (its attributes, relationships etc.), and the definition of the persistent store must be changed accordingly.

Adding persistence to an application design complicates the run-time flow. If an RDB (relational database) or OODB (object-oriented database) is being used as the persistence store, it is typically implemented as a set of processes running on the application host or another machine. Debugging the run-time flow becomes more complicated, since:

References to objects may vary, depending on whether the object is in memory or only available in the persistent store.
The notion of object "identity" becomes important. As objects are retrieved from the persistent store, it becomes very important to know if two objects represent the same object in the persistent store (and in the real world).

Performance may be dramatically diminished by using a database. Anyone who has ever written embedded SQL in a traditional C or C++ based RDB implementation knows that after all of the code is written and tested, the real work begins. Tweaking the SQL to optimize the performance of the application is a difficult and time-consuming task.