Consequences

The Object/Relational Map pattern has the following consequences:

Tradeoff

• Depends on additional commercial product— Most applications already depend on a commercial database, one or more database drivers, and an application server. If you use object/relational mapping extensively, you are likely to benefit from integrating a commercial object/relational mapping product as well. Buying a commercial product saves you a significant amount of development expense. However, redistributing third-party software does require you to address additional legal, packaging, and installation issues.

Benefits

• Has clean application code— Application code that works exclusively with domain objects is much cleaner and easier to develop and maintain than code that includes data model and data access details. When an application uses well-defined domain objects that expose only logical attributes, its code can focus more on its own domain logic. In addition, you are in a better position to alter the data model or data access details later.

• Maps to alternate data models— The most versatile object/relational mapping mechanisms isolate configurable map metadata that you can change without affecting application code. Many object/relational map products store and interpret map metadata at runtime so that changes do not require any code to be recompiled.

  The concept of mapping to alternate data models has powerful consequences. It is common for data models to be bound by their applications. This characteristic severely restricts data model changes because they require extensive software upgrades. Encapsulating data model details within metadata enables you to make changes such as rearranging tables, moving to different platforms, or even moving to a different type of data store such as an XML-based or object-oriented database.

  Metadata is also beneficial because it enables you to quickly adapt your applications to alternate data models. This is especially significant from a marketing and demonstration perspective since you can quickly configure your application to work with a prospective customer's legacy data. Prospects are more likely to be interested in your demonstration when they see it in the context of their own data.

Drawback

• Limits application control of data access— Application code is limited to the operations that the PersistenceManager interface defines. Since the Concrete-PersistenceManager encapsulates data access details, it is harder to tune its physical database operations and resource management to optimize data access performance for a particular application. This especially holds true if you employ a commercial object/relational mapping product.