|
Building Scalable Database Applications : Object-Oriented Design, Architectures and Implementations
 |
Author: Peter Heinckiens
List Price: $39.95
Our Price: Click to see the latest and low price
ISBN: 0201310139
Publisher: Addison-Wesley Pub Co (09 February, 1998)
Edition: Paperback
Sales Rank: 72,641
Average Customer Rating: 3.33 out of 5
|
Customer ReviewsRating: 5 out of 5
Brilliant
I think some of the other reviewers might forget this book is at the time of this review writing is 5 years old. At the time of .NET's official non beta release it was just over 3 years old. Truly, this book is as relevant today as it was when it was written. Perhaps some of the concepts of persistence are missed by the first reviewer in context of .NET and certainly with the impending object-spaces microsoft technology much of this may be moot. I certainly do believe that GUI's are very much tied to the business model (ESPECIALLY in .NET apps) and I have benefited tremendously in perspective by applying the database conceptually as another view to my business model.At any rate, excellent theory and interesting approaches to implementing a persistence architecture. Certainly I do not agree with everything I read but it offered a new perspective to a fascinating problem. A very worthwhile and applicable book on all levels. Worth the price.
Rating: 1 out of 5
A waste of time
There must be some kind of curse with books on objects and persistence. After being deceived with some book by Sessions some years ago, now I got seriously disappointed with this one. This 300-page book suffers from the "big wait" syndrome: it introduces the major topics again and again, each time maybe being a little more specific in some areas, but does not delve into central stuff until 80 pages have happened. That is reinforced by a broken rythm and too short sections that end when they are leaving introductory stuff and starting to turn interesting.Also, it contains a number of inaccuracies and inconsistencies. Naming conventions are awful or absent, both from the syntactical and semantical viewpoint; see code in p. 68 for a specially relevant example. A book with so much printed code should pay attention to this. Also, some concepts are plain wrong: tables using foreign keys pointing to other tables are not "joined" but linked or related (p. 51). Joining may come later through specific SQL queries using the JOIN keyword. Classes related to other classes don't necessarily result in objects "containing" other objects (p. 52), but referencing them. Most central to the book, the author claims that IM resolvers solve the problem of making library classes of which we don't have the source code persistent. What about privately held state? You cannot solve this problem as an afterthought without a good metainformation-based reflection infrastructure such as that of .NET, for instance. I don't think the Scoop architecture is much better than any other way to make objects persistent. Also, attributes are usually considered scalar properties of classes, but the author omits the "relation" or "reference" concept and uses "attribute" to mean any property of a class (p. 58, p. 71). Later, he discusses the issue (p. 176) but the conclussion he draws contradicts his previous use of the concept! Overall, the book shows a lack of sound conceptualization of object-oriented ideas, and is too geared to the pure programming of persistent objects from a clearly narrow perspective. The author ignores high-level persistent libraries (such as ADO in the Windows platform) and puts too much importance in C++, which definitely is not the most used language in database environments. For instance, the identifier of an object is not the memory address it occupies. That's just a not so convenient way to build object ids. The author builds on top of this by saying that an untrained programmer could start using Visual Basic in a few days; of course, my 3-year old daughter could also start moving pieces on the chessboard right now. But that does not mean she plays chess!
Also, I totally disagree with his proposed parallelism between databases and user interfaces. His viewpoint only can be defended if you consider purely _structural_ UIs such those generated by (bad) 4GLs and some ERP parameterizable environments. Complex application domains (are there simple ones?) require highly _functional_ UIs that do not map the database in any sense. I feel deceived about this book. I spent my money in a work edited by Addison-Wesley, which is a reputated firm from which I have read dozens of brilliant books, and this one does not keep the minimum level. The book cover shows the names of Mary Loomis and the Three Amigos, which undoubtedly endorse the book's value. What's their value?
Rating: 3 out of 5
Not a total waste
Adapting the particular solution for non C++ languages is difficult.The use of operator overloading in this book only obscures and does not illuminate. I completely disagree with his "DataExplorer" GUI classes. On the plus side there are a few good ideas to be mined.
Similar Products
· Principles of Transaction Processing
|
