Data Access Patterns: Database Interactions in Object-Oriented Applications
 |
Author: Clifton Nock List Price: $49.99 Our Price: Click to see the latest and low price ISBN: 0131401572 Publisher: Addison-Wesley Pub Co (15 September, 2003) Edition: Hardcover Sales Rank: 40,517 Average Customer Rating: 4.33 out of 5
|
Customer ReviewsRating: 5 out of 5 Good design pattern book in data access !! 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 Rating: 5 out of 5 Excellent and Easy To Read 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.After reading numerous pattern books, it is nice to see a pattern book with very good organization. Each pattern is presented with the following subsections. * Description * Context * Applicability * Structure * Iteractions * Consequences * Strategies * Sample Code * Related Patterns and Technology. I specifically like 'Consequence' section because it outlines the 'bad' consequence of adopting the patter. This goes with the mantra of design patterns - there is no one good pattern. You trade off one design for another depending on the context of your domain. Also each pattern is accompanied by UML class diagrams and UML sequence diagrams - this is a big plus in understanding pattern. The sample code is written in Java/JDBC so you may need to understand Java but I believe this pattern is still relevant to ADO.NET and C++. [ ADO.Net does offer connected and disconnected database operation so some patterns may not be relevant - plus, event/delegate will aid in some patterns.] Specific to what the previous reviewer say - here are my rebuttals. >> Why do you want to make queries and database updates into factories? Looking at the sample code, does it really help decoupling? The previous reviewer mentioned as 'factories' is the derivation of 'AbstractFactory'. If you do not understand why AbstractFactory aids in decoupling from the concrete implementation, I think you should re-read GoF book. The author uses AbstractFactory pattern extensively in context of "Input and Output Parameter" and "Cache Patterns". I do admit that sometimes "Input and Output Parameter patterns" may not need to use AbstractFactory but if you read 'Domain Assembler' pattern you will understand why. From Domain Assembler, you can see the benefit of having AbstractFactories for Selection, Domain Object, and Update -- assembling all these factories via interface not concrete implmentation - a basic idea of design to interface instead concrete implementation. >> The "Cache Patterns" does not solve the problem of preventing stale entry or even attempt to describe how to invalidate cache entry, so no matter how efficient you get, the cache is not guaranteed to be up-to-date /correct. Please re-read 'Cache Collector'. The pattern could have different name like 'Cache Garbage Collector'. He talks about how you can 'purge' old data. Also re-read 'Cache Replicator' for how to sync the cached data in distributed system. >> I'm surprised "stored procedure" is not mentioned at all. I guess you have not done too many DB oriented projects. The stored procedure is evil and add little value to OO programming. But if you want the stored procedure, just replace 'SELECT' or 'UPDATE' statements to whatever stored procedures you want to call. So I don't think you can add much with SP. >> mature object/relational frameworks like EOF (Apple WebObjects) or TopLink This book is not about Java Data Object or OR mapping. Object-Relational mapping tool is another beast. I would recommend this book highly to anyone doing DB application development. Rating: 3 out of 5 Not good enough. 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. But this book leaves a lot to be desired.There seems to be the problem of having patterns just for the sake of having patterns. For example, why do you want to make queries and database updates into factories? Looking at the sample code, does it really help decoupling? How come you can only get the first page from the "Paging Iterator"? Besides giving hints to JDBC, the pattern gives no control over the rows actually returned from the database. The "Cache Patterns" does not solve the problem of preventing stale entry or even attempt to describe how to invalidate cache entry, so no matter how efficient you get, the cache is not guaranteed to be up-to-date /correct. I'm surprised "stored procedure" is not mentioned at all. The overall organization and format of the book is good, but for experienced database application developers, you might learn more by studying mature object/relational frameworks like EOF (Apple WebObjects) or TopLink.
Similar Products
· Agile Database Techniques : Effective Strategies for the Agile Software Developer
· Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems
· Domain-Driven Design: Tackling Complexity in the Heart of Software
· Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions
· Patterns of Enterprise Application Architecture
|