Data Access Patterns: Database Interactions in Object-Oriented Applications

Hardcover

ISBN 10: 0131401572 ISBN 13: 9780131401570

Publisher: Addison-Wesley Professional, 2003

25 proven patterns for improving data access and application performance Efficient, high-quality data access code is crucial to the performance and usability of virtually any enterprise application--and there's no better way to improve an existing system than to optimize its data access code. Regardless of database engine, platform, language, or application, developers repeatedly encounter the same relational database access challenges. In Data Access Patterns, Clifton Nock identifies 25 proven solutions, presenting each one in the form of a clear, easy-to-use pattern. These patterns solve an exceptionally wide range of problems including creating efficient database-independent applications, hiding obscure database semantics from users, speeding database resource initialization, simplifying development and maintenance, improving support for concurrency and transactions, and eliminating data access bottlenecks. Every pattern is illustrated with fully commented Java/JDBC code examples, as well as UML diagrams representing interfaces, classes, and relationships.The patterns are organized into five categories: *Decoupling Patterns: Build cleaner, more reliable systems by decoupling data access code from other application logic *Resource Patterns: Manage relational database resources more efficiently *Input/Output Patterns: Simplify I/O operations by translating consistently between "physical" relational data and domain object representations of that data *Cache Patterns: Use caching strategically, to optimize the tradeoffs between data access optimization and cache overhead *Concurrency Patterns: Implement concurrency and transactions more effectively and reliably Data Access Patterns demystifies techniques that have traditionally been used only in the most robust data access solutions--making those techniques practical for every software developer, architect, and designer.

About the Author:

Clifton Nock is a senior software architect at PeopleSoft in Denver, Colorado. He spent five years at IBM designing programming interfaces that simplify access to the iSeries operating system and its integrated database and holds nine U.S. patents relating to this work. He has taught several programming courses at the University of Minnesota and presented at technical conferences worldwide. He holds an M.S. in Computer Science from the University of Minnesota.

Excerpt. © Reprinted by permission. All rights reserved.:

Preface

Data is a major element in the foundation of any enterprise.Accountants make and defend decisions using financial data.Manufacturers and purchasers rely on stock and order data to temperinventory. Salespeople study customer history data. Executive managementdepends on data to examine company controls.

Enterprise software enables these key decision-makers to read, write,and organize data. Data access facilities within business applicationsplay an important role in their quality and usability. Developers mustexert considerable effort to design efficient data access code,otherwise an entire application may appear to be slow or prone todefects.

Data Access Patterns Enterprise software developers tackle the same dataaccess problems regardless of their application domain. These are someexamples of common issues that arise when designing data accesscomponents:

• Applications need to work with multiple database products.
• User interfaces need to hide obscure database semantics.
• Databaseresource initialization is slow.
• Data access details make application code difficult to develop and maintain.
• Applications need to cache data that they access frequently.
• Multiple users need to access the same data concurrently.

There are common solutions to these problems. Some ofthese solutions are intuitive and have been discovered independently byliterally thousands of developers. Others are more obscure, and havebeen solved in only the most robust data access solutions.

Data access patterns describe generic strategies for solving commondesign problems like these. A pattern does not necessarily dictate aparticular implementation. Instead, it describes an effective design andstructure that form the basis for a solution.

This book describes patterns that apply specifically to relational dataaccess. Relational databases are by far the most prevalent and provendata storage mechanism that enterprise software uses today. Otherpersistence technologies, like object-oriented and hierarchicaldatabases, are gaining in popularity. These alternative databases storedata closer to its runtime object form, so conventional object-orienteddesign patterns and techniques apply more readily.

Who Should Read This Book?

This book is intended for softwarearchitects, designers, and engineers who are responsible for buildingdata access software components. In addition, the material in this bookis also appropriate for students who wish to understand common dataaccess problems and solutions.

This book describes data access patterns using common database andobject-oriented concepts and terminology. It is expected that the readerhas a basic familiarity with both of these. If you run across a termthat is not familiar to you, please consult the glossary at the end ofthe book.

The patterns in this book apply to many platforms, programminglanguages, and databases. The sample code for each pattern is writtenusing the Java 2 Standard Edition (J2SE), Java 2 Enterprise Edition(J2EE), and Java Database Connectivity (JDBC) APIs. The sample codeexpresses database operations using Structured Query Language (SQL). Abasic understanding of Java and JDBC is helpful when studying thissample code, but it is not essential. Comments and explanationsaccompany any code that is not straightforward.

How This Book Is Organized

This book is a pattern catalog. It describes a set of dataaccess patterns in detail. The parts of the book group multiple patternsbased on their applicability. Since it is a catalog, do not feelcompelled to read the pattern descriptions in order. If a patterndepends on concepts that another pattern defines, it clearly states thisfact.

Patterns are identified by concise, descriptive, and familiar names.Pattern names are significant because you can use them in conversationand documentation. It is much more effective to describe a set ofinteracting classes as an instance of Resource Decorator than torepeatedly describe each element of a pattern in detail.

This book's "Introduction" presents the motivation for studying andapplying data access patterns. It briefly introduces each pattern. Thischapter also defines the form that subsequent chapters use fordescribing pattern details.

The remainder of the book is the pattern catalog, divided into parts foreach pattern category:

Part 1, "Decoupling Patterns," describes patterns that decouple dataaccess code from other application logic, resulting in cleanerapplication code that is less susceptible to defects caused by changesthat relate only to data access details.

Part 2, "Resource Patterns,"describes patterns for efficient database resource management.

Part 3,"Input/Output Patterns," describes patterns that simplify data input and output operations using consistent translations between relational data in its physical form and domain object representations.

Part 4, "CachePatterns," describes patterns that enable strategic data caching and address the tradeoffs between data access optimization and cache overhead.

Part 5, "Concurrency Patterns," describes patterns that implement concurrency strategies.

The inside front cover provides a reference listing of the patterns in this book and their descriptions.As you become familiar with the book's structure and the pattern form,you may find this listing convenient for identifying and quicklylocating a specific pattern.

Summary

Like any other pattern catalog, this book is not exhaustive. Youare encouraged to tweak the solutions to fit your applications anddiscover new data access patterns along the way. Using and identifyingpatterns is beneficial, even if you do not document them as formally asthose in this book.

I am genuinely interested in any feedback and insight that you haveregarding the patterns described here. You can write me in care ofAddison-Wesley or send e-mail to dataaccesspatterns@awl.com.