Patterns of Enterprise Application Architecture [Hardcover]

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

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.

So what is the problem? The title is misleading. It is about patterns, but not really about enterprise applications. I am not in the subject of enterprise applications. I never ever have touched a program like SAP or a language like COBOL. But I encountered nearly every problem addressed in the patterns. Even the money class has corresponding problems in other fields: a Voltage has both a value and a unit. Also having complaints about the fact that 3 times 33% are less than 100% are always common.

What is this book about? It is basically about problems you have in moderately big applications. How do you connect a relational database with its structure and transactionality to a system, especially an object-oriented system (but not only)? And how do you connect to the user interface, especially a web interface. Also it contains a lot of useful small patterns at the end. As you can see: a lot of valuable stuff for many people. Yes and you get the deep judgments and fine humor of Martin Fowler too.

What is the main problem? This book is not really suited for actual reading. It contains an introductory part of a hundred and a reference part of four hundred pages. The introduction part is annoying to read. It is at the same time too simple (Some knowledge of relational databases should be a requirement for this book, and much more...) and too difficult (An extremely lot of forward references to patterns described later in this book). Also a lot of stuff is in the most trivial sense repeated within a few pages distance only. And it is repeated down to the wording of the individual sentences.

The reference part is a lot better. It gets better to read the further along you already read. The number of forward references gets less along the way. I liked especially the last part about base patterns. As their name already says they should have been much more to the beginning of the book.

This book contains an excellent book within it, just waiting to be "refactored" out of this collection of valuable thoughts. I firmly believe that Martin Fowler is well suited to do this refactoring job. I do sincerely hope that he does it for the next edition of the book. Most of the work is already invested and the result would be very valuable for many people. It is possible to write excellent and readable books about patterns as for example Buschmann et al in "Pattern Oriented Software Architecture" showed.