Rating: 
Summary: Interesting But Muddled
Review: Overall, I was disappointed by this book. I develop business applications, and I was hoping this book would provide practical insights about such applications, more specifically in the database/web realm. While this book does contain some interesting pieces of information, it really is not of immense value to a developer such as myself. Here's why:This book is a bit of a mishmash of different topics, but the vast majority of it (I'd say 75% or more) consists of ideas for object-relational mapping. Since most developers would use existing tools for object-relational mapping (in the Java realm, see Hibernate, JDO, etc.), I fail to see the real usefulness of this book for most developers building business (web) apps. Further, this kind of book encourages people who don't have the necessary expertise to try rolling their own OR mappers, which is simply not a good idea. It's too bad, because the book starts off promisingly enough with 3 general approaches to business apps: Transaction Script: The procedural/transactional approach; Domain Model: The OO approach; and Table Module: The data-cetric approach. So far so good. Unfortunately the book then seems to steer off to the topic of "Fun With OR Mapping." It's not as sexy, but I think that's perhaps what the title of this book should have really been! The book then goes on to talk about different ways to architect Web applications, again mostly getting into how to develop framework code, which one largely would take for granted if one is deciding which framework to use rather than rolling one's own. Finally the book talks a bit about locking strategies (pessimistic, optimistic) and then presents a few generic items (e.g. the concept of a Money class or a Registry class). Only a very small fraction of this book will be useful to a non-framework developer. Also, even though this book claims to be technology-agnostic, it seems rather firmly planted in the Java world. I'm not convinced an ASP/ADO.NET developer would find it particularly useful, for example. I think there is an important need to demonstrate how to put together solid business applications. I'd love to see a book of recipes that says "here's how to develop an ASP/ADO.NET app; here's how to develop using EJB; here's how to develop using Hibernate..." but without all the distracting details of how to implement the whole solution from scratch -- Basically I want a book that relies on the idea that frameworks are out there, but focuses the developer on how to choose a framework and how to take advantage of frameworks to produce solid, maintainable solutions. Lastly, I would say Core J2EE Patterns from Sun Press is a more useful book for the Java/J2EE crowd, though it too suffers from framework-itis.
Rating: 
Summary: one of the best
Review: Probably the best general application architecture books out there. The only time this book gets specific to a proprietary technology is in the examples only because martin wants to show you a real world example of what he is talking about. There are examples in C#, some in java, etc. It is organized very well and if you were around when he was developing it you could have gotten the whole book in pdf form for free!
Rating:
Summary: Solid Guidence for Enterprise Developers
Review: The book is divided pretty well, the first portion of the book is a concise overview of the thinking behind most of the patterns presented later in the book, so if you don't want to read the technical details of every single pattern, the first portion of the book is a great way to get some hints as to which patterns might fit your needs. The remainder of the book focuses on the pros and cons of each approach as well as sample implementations to give you more concrete guidence on implementing the patterns (topics covered by the patterns cover a wide range of areas mostly dealing with table and object approaches for passing data, concurrency issues, and presentation layer implementations). Most Enterprise developers have probably used at least few of these patterns for projects they have worked on, but it is nice to have a list of pros and cons of each pattern as well as additional alternatives that you might not have encountered or had a chance to implement. This book is a must have for developers that are new to Enterprise Architecture. Advanced developers probably will not be shocked by any new / exciting revelations, but will still find the book to be a worthwhile read and a source of sound guidance.
Rating:
Summary: A Perfect 10
Review: There is a good reason why this book scored 10/10 in a Slashdot review. Fowler writes with such clarity and organization that even the most complex enterprise architecture concepts are handily broken apart into manageable chunks (patterns). For instance, Fowler attacks the challenge of object-to-relational data mapping by breaking it into architecture, behavior, structure, and metadata patterns. The result is a set of clearly defined, vendor-neutral, "concept tools" that the reader really knows when to use. This book is to enterprise app design what the classic Gang-of-Four book is to OO design.
Rating:
Summary: An indispensible guide for Architects and Developers
Review: This book brings together the collected wisdom of the J2EE and .NET communities in a single volume that shows how you design and build "real-world" enterprise systems. The patterns themselves are classics -- for instance it's great to finally see all of the basic patterns of object-relational mapping in print -- but what really ties this book together is the connecting text that links the patterns together into a cohesive whole. Martin has successfully shown how to use patterns to link together all of the parts of an enterprise system -- drawing from the work of John Crupi et. al. in "Core J2EE Patterns" but going far beyond the scope of that book. I think this book will have the biggest impact on the OO community since "Design Patterns" and just may make patterns "cool" again!
Rating:
Summary: A Comprehensive book
Review: This book gives a catalog of patterns for enterprise solutions based on layered architecture(he has not covered the filter/pipe pattern). It provides multiple probable solutions(In C# and Java) for many enterprise related issues/problems. Most of these issues are shared by J2EE/.NET/CORBA framework based applications. If the user has already read J2EE Design Patterns, Design Patterns(Gang of Four) books and worked on 3-4 Enterprise multi-layer applications, then this book makes a lot of sense. The solutions can be put to practice fairly easily , atleast in the J2EE app server based solution space. BTW, this books is out of stock at Amazon, I ordered my copy from Barnes and Noble and got a good discount too. The book was on the net for a while on martinfowler.com site and only after it was published at OOPSLA 02, was it removed. Going through the June 02 snapshot of this book provided for interested reading. The final version has been edited for easy reading and comes out pretty well. CONS :
1) Does not come with a CD :-)
2) Does not use all(advanced) language facilities (to make it readable)
Rating:
Summary: Good, but not great
Review: This book has been getting a lot of hype -the followup to Fowler's seminal Refactoring, enterprise edition of the GoF, etc etc. It's a dense and informative read. If you didnt know anything about cricket, you will by the end, as all its examples are basd on the game. I, sadly, find cricket deadly dull as a consequence of having it force fed at me in the UK educational system. This may bias me against the examples somewhat. As to the content, well, it is a set of patterns focused on 'enterprise' applications. In this context, enterprise means server-side code connected to a database, usually with a Web Front end. Martin goes into superb depth on how to map from databases to java and .net objects, making you think about whether or not the stuff that your framework of choice gives you is the right tool for the job. Sadly, all that does is make you more aware of the failings of EJB, JDBC, whatever .NET has. Because, unless you are going to roll your own database bridge by hand, you are going to have to run with what they give you -whether it [stinks] or not. I dont do much O/R mapping. I hand it off to tools like Castor and worry about my real problems: shipping web services to implausible deadlines to be managed by an operations team that phone me whenever something goes wrong. So my problems are web service related 'good API design', and 'executional patterns': how to design code that is easily tested, what is a good strategy for implementing configuration information, what is a good XML format for future flexibility. I also have to worry about the client side: how to architect a client that works well over long haul and intermittent links, and how to present this to the user. Martin's book doesnt cover these kind of problems. I do like his critique of Entity EJBs (as opposed to session beans), where he observes that because EJBs are all distributable, people tend to do just that, leading to performance problems that are very profitable to him as a consultant. The implicit message is that these days, he is spending his time tuning object to DB linkages, and not worrying about all the other aspects of the problem. Another reviewer mentioned security, but my concern is about designing for high availablity, a series of practises that focus on redundancy, caching, and interdependencies and self-diagnosis of faults, rather than caring about minutae of O/R binding. So I'm giving the book 3-stars, as it doesn't suit my problems. Maybe it suits other people better. -steve
Rating:
Summary: Design Patterns at the implementation level for J2EE, .NET
Review: This book is a little more implementation specific than the incredibly popular Gang of Four Design Patterns book. Many of the patterns, the Data Transfer Object pattern, for example, are fairly specific to the J2EE structural problem at hand. Other patterns, like the Lazy Load, are good architectural patterns on any platform. There is enough generic content to justify the purchase of the book for architects implementing on any platform (J2EE, .NET, PHP, etc.) but it does favor the two current platforms de jour; J2EE and .NET. One of the nice things about the book is how the code tends to de-emphasize the application container by doing most of the work in the raw database access systems (e.g. JDBC), which makes it easy to understand what is going on but will offend the true J2EE believer. This makes the patterns in the book accessible to anyone coding in any environment, which I greatly appreciate. One pet peeve is that some of the patterns are obvious shells for a single technique, such as the Transform View, which is really just XSLT. The text says as much, but shouldn't there be more than one example of a particular pattern in nature? It's just a pet peeve though, it's no reason to avoid the book. Overall, the book is well written and edited and the graphics add to the exposition but are not gratuitous. It's a useful guide for anyone looking to raise the level of the enterprise application (read web application) thought up to the next level.
Rating:
Summary: Brendan Johnston
Review: This book is an enjoyable and well writen book about IT. Fowler's offers candid expression of the limitations of the ideas, and the nature of the development world. This book also gives a perspective on some of the important architectural issues in enterprise applications. Fun to read and valuable, this book deserves 5 stars. Can it lift architectures of enterprise applications to a higher level of abstraction, well maybe not. I *got* the GOF "Design Patterns" book after a lecture from Richard Helm. I realized that simply identifying structures that frequently exist, can help to organize complexity, so my thinking could move to a higher level of abstraction. Since then patterns have typically made development much more complex. We could be simply naming the patterns that are necessary to implement a function. But this is not happening, architects instead follow this advice from the book "Core J2EE Patterns": "using this pattern or its strategies results in only a small amount of additional upfront work and provides considerable benefits." So every conceivable pattern gets stuffed into applications creating an unbelievably complex "best practice" system. At least you would hope that given the small number of patterns in GOF, and its acceptance as a standard, that people would use the names faithfully. This does not happen, the architects I work with more commonly misuse the pattern names, than use them correctly. Fowler's book is less accepted and has more patterns so I assume it will be worse, so in two year time no one will know what I mean when I say "Transaction Script". So this work will not enable us to communicate better. This book is not as timeless, or academically correct as "Design Patterns". The editing is somewhat inconsistent. The explanations are less precise and formal but easier to understand. If you read this book you will be able to think more clearly about structures in your systems. You will understand this book if it applies to the systems you are building. This book is good to read and related to what I do.
Rating:
Summary: A masterpiece of pragmatism
Review: This book is an enthralling read. It is full of sound advice, tips, traps, and just plain old good common sense -- not to mention the patterns. The patterns, like all good patterns, are not new. They've been around for a long time. However, in this book they are very well identified, specified, clarified, and classified. Martin's writing is brilliant (as usual), and he brings the patterns to life with just the right mixture of prose and code. Superb!
Just as Design Patterns did seven years ago, this book will become the basis of a vocabulary that we will use from now on to speak about information system's architecture. This one goes on your shelf right next to GOF -- but make sure you read it before you put it there!
| 
