Data Access Patterns: Database Interactions in Object-Oriented Applications (paperback)

Nav:Home > Textbooks > Computer Science > Data Access Patterns: Database Interactions in Object-Oriented Applications (paperback)

Press:Addison-Wesley Professional Addison-Wesley Professional; 1 edition (September 21, 2003)
Publication Date:2003-09-21
Author Name:Clifton Nock
Edition:1st Edition


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

--This text refers to an out of print or unavailable edition of this title.


Textbooks,Computer Science,Object-Oriented Software Design,Computers & Technology,Databases & Big Data,Data Modeling & Design,Database Storage & Design

 PDF Download And Online Read: Data Access Patterns: Database Interactions in Object-Oriented Applications (paperback)



Comment List (Total:7)

  •     First of all this book is not about object relational mapping (ORM) strategies or patterns, the author provides a pattern that is the interface to a object relational mapping...
  •     I am in the process of writing a thesis proposal that utilizing JDBC and TableModeler to access various database platforms as a prototype.While prototyping the model, I encountered a lot of consideration of what is the best approach for certain implementation (mainly on JDBC). While looking into a few of designing books, I found this Data Access Patterns book that fits into my research needs. I have read other book such as Designing Flexible Object Oriented System with UML and not able to apply the concept or see solution in it. It is simply a conceptual book. No practical examples at all.Mr. Nock has explained the design patterns very clearly in each chapter by using JDBC as a media. The examples are very easy to understand as compared to Design Patterns Explained. I am not able to understand codes that implementing graphics in that book.Mr. Nock addressed the pros and cons of the patterns. Many techie books do not even bother to talk about pros and cons.The author has chosen the right title for the book, I realized that many times author received a poor rating because reader expect different contents based on the title of the book.The feature I liked the most - the ¡§Applicability¡¨ section on each chapter. Unlike other patterns book, the author explains the concept and gives example of "what" and "when" to use certain design pattern. This section is pretty much the answer for my thesis obstacles. The answer is in this book!!Minor typos do exist such as in page 390 roll back instead of rollback.In concurrency chapter, author may have mis-used the term of updates locking. It should be Lost Updates instead of Missing updates. Concurrency chapter looks like UDB Lock Concurrency architecture.Additional note - would like to see the quality aspect in each of the patterns.Overall, the book is very well structured, explained and thoughtful.Thank you Mr. Nock !! This is a perfect book for my thesis.Looking forward to read your future publish.Regards,EQ
  •     Having read GoF's "Design Patterns" and "Design Patterns Smalltalk Companion" in the series, I grabbed this book as soon as I see it in store.
  •     I'm in the middle of developing yet another persistence framework for a client, having done it a couple of times before. Each time I refine my ideas about how to do it. I must say that this book has a thorough examination of issues and certainly food for thought as well as answers to a couple of questions I've had.However, I wouldn't say it's a complete design (which it doesn't claim to be). I still found myself picking and choosing which patterns to use as is, which to modify to my liking, and which to discard.Also, I was left with the impression that the book didn't give enough coverage to handling collections of objects. The material is mostly geared toward working with a single object, which is understandable. I just think it would have been helpful to have more discussion about handling collections. For example, what should happen when you request to load an object, but the criteria you passed to the loading mechanism results in data for more than one object being retrieved from the database? Hand back the first object? Raise an exception? If it's covered in the book, I missed it.Further, I would like to see more discussion about WHEN to refresh an object from the underlying database and when to save to the database. I always struggle with that timing issue. Having studied EJB, I like how entity beans keep your bean in synch with the underlying database. But the EJB container intercepts calls and makes those things happen. When coding the persistence layer myself, that's not an option. So, again, this is something I'd like to see some light shed on.Overall, though, a great book if you're interested in reading up on persistence layer patterns.
  •     I have to disagree with the previous review. I will try to explain why I think 'b88zhou' review is inadequate after presenting my overview of this book.
  •     The book presented 25 patterns grouped in 5 areas, decoupling (conceptual and architectural level), resource, input/output, cache and concurrency.The most interesting patterns are in resource and cache. Decoupling and concurrency patterns (e.g., data accessor, active domain object, layers, transactions, optimistic/pessimistic lock etc.) are well known and the contents are a bit too light to be very useful, yet the concepts are giving readers some directions.In resource patterns, some interesting patterns are presented, particularly resource timer automatically releases inactive resource, retryer enables fault-tolerance for data access operations.In cache patterns, cache collector purges entries whose presence in the cache no longer provides any performance benefits; cache replicator replicates operations across multiple caches.There are some areas to be improved, first, author should consolidate pattern names with other pattern authors, e.g., data accessor is also known as data access object, active domain object is similar to active record, paging iterator is close to value list handler (though value list handler is more decoupled from underlying data store), the point is, one of the important benefits and purposes for documenting patterns is to build common vocabularies among designers, using different names for same or similar patterns is defeating this purpose. The same pattern name should be used and may be presented as a variation of the original pattern.Secondly, the examples given in the book is a bit too simple, sometimes, the examples might not justify or validate the interface abstraction is generic enough to handle real world problems, so some tweaking and modification to the pattern would be expected.Overall, the book is well organized, and contents are easy to follow, most patterns come with class diagrams and sequence diagrams. Good for designers who want to decouple data access from rest of the application, utilize cache to minimize data access and thus boost application performance, manage resources in an efficient and leaking-proof way.
  •     Try Martin Fowler's Patterns of Enterpise Application Architecture.It has much better coverage in more useful context.

Recommand Books


Legal Theory & Systems,Cooking Methods,Physics,Dentistry,Other Team Sports,Infantil y juvenil,Cars, Trains & Things That Go,Christian Denominations & Sects Book,。 FreeBook 

FreeBook @ 2018