Introduction

Nearly every enterprise application is backed by persistent data. An application's data is often worth considerably more to its users than the application itself. The majority of many systems' resources are dedicated to implementing and managing data access details and logistics. For this reason, it is important to understand both your data's structure and application's interactions with it in detail so you can tune both for efficiency and maintainability.

A thoughtfully designed data model is the best foundation for efficient data access. Normalized databases with properly defined indices result in more efficient queries and updates. More often than not, programmers and designers are not at liberty to alter or redefine existing data models. Changing an aspect of a data model from one software release to the next might require complicated table conversion processes that disrupt an enterprise's computing environment during an upgrade. In addition, your customers are likely to have built their own custom applications or reports using the data. Changing the data model forces your customers to upgrade these as well. This is likely to deter them from upgrading at all.

Optimizations to data access code are a much more feasible approach, since implementation changes require only the installation of new software. Operations associated with data access can easily be the most expensive in an entire enterprise system. Naive or inefficient data access code makes the difference between streamlined, transparent throughput and slow response times. It follows, then, that data access code is a perfect candidate to target when investigating major optimizations.

Another area to consider where data access strategies pervade is maintenance. Data access code that is spread across many components is difficult to change and optimize, let alone comprehend. Data access code is best left encapsulated within a small number of components so that it is more maintenance-friendly.

The same data access issues tend to arise across a wide variety of application domains. Financial, human resource management, inventory, and customer tracking software can have vastly diverse data models and user interfaces, but still suffer from common data access bottlenecks such as connection overhead, superfluous queries, and concurrency problems.

Just as the same issues appear in many types of applications, developers have solved these problems with common strategies. For example, numerous applications incorporate connection pooling as a mechanism for reducing connection initialization overhead. As this practice became more prevalent and publicized, developers utilized it to improve a growing number of software products. Ultimately, connection pooling has become a common data access optimization strategy supported by many commercial middleware products and defined by standards.

Resource Pool (117) is an example of a data access pattern that has been identified through the abstraction and refactoring of multiple, independent connection pool implementations. Like most of the patterns in this book, it applies to many application domains and platforms. This chapter illustrates how to identify and apply data access patterns and introduces the data access patterns described in the remainder of this book.