J2EE Design Patterns

Object-Relational Mappings

So far in this chapter, we’ve assumed that the table structures for the business objects we’re working with are known in advance. This is generally true when adapting legacy systems or coming into a project mid-way, but not when starting from scratch

When building new applications with a persistent backend (and that’s pretty much always, whether a database is involved or not), you obviously need to design the persistence approach. Persistence models are much harder to change than other areas of an application, particularly when a version of a system has been moved into production use. Data must be either abandoned, an option that is generally not smiled upon by senior management, or converted, which is time-consuming and error-prone. Although modern database tools have made the process much easier and more flexible than in the past, there’s still lots of pressure to get it right the first time.

Developers extending an existing application have it both easier and harder than those working on something new. In an existing application, the philosophical approach to persistence has usually already been chosen, so developers adding new features don’t have to reinvent that particular wheel. On the other hand, adding a substantial amount of new persistence functionality to an existing system can involve stretching existing tables and methodologies beyond their original design intent, and it always involves migration hassles. Attempts to minimize migration efforts ...