Persistent Objects


Most programs have a common problem: they want to save part of their state, (i.e., part of their objects), in certain moments to make sure they survive the end of the program run. This process is called persisting. In another moment, and frequently in another program run, persistent objects should eventually be taken back from their exile to operative use. There are many options to make data and objects "durable" in Java. Typical variants include:

A full discussion of the benefits and drawbacks of available persistence mechanisms goes beyond the scope of this tutorial. These issues are covered in the literature [Barry96], which discusses in detail why and how an OODBMS can make our coding life easier. After all, we developers would like persistence to become a seamless part of object-oriented principles. In contrast, more than 10 years after the appearance of the first commercial object-oriented databases, most companies still favor their relational counterparts for software development, for good or bad reasons. In this chapter, we concentrate on the RDBMS variant and on Java database connectivity (JDBC) as a standardized coding interface to databases. The following problems occur when testing relational objects:

Other persistence mechanisms can cause the same or similar troubles. These problems contribute to a situation where many developers who had initially been happy to work with the test-first approach throw in the towel when trying to integrate the persistence mechanism. This chapter explains how a combination of certain design principles and techniques can help to make unit testing for and with persistent objects less painful. [1]A mapping tool maps objects to relational tables. One of the most popular tools of this kind is TopLink [URL:TopLink].