« Sun: 5 year plan | Main | Here be dragons »

review: Patterns of Enterprise Application Architecture

Patterns of Enterprise Application Architecture

Patterns, Enterprises and Architectures, oh my! But the most important words on the cover are "Martin Fowler". He has already written three fine books on software development. I want to do two things - first say some nice things to encourage you to read it (it's a great book), and second, concentrate on the things I didn't like so well.

The format is similar to Refactoring, geenral discussions at the beginning and end, the patterns catlog in the middle, with cheatsheets and a list inside the covers. That makes it easy to dip in and out of the text, and like Refactoring it should become a valuable communications tool for developers, providing a vocabulary for application development. Much of the book deals with the mismatch between objects and relational databases. Fowler tackles that problem head on, with nearly twenty patterns and a chapter devoted to it. If you are working against an object-relational boundary, or protecting your application from database dependencies and find the GoF book dated or irrelevant, this is an excellent resource. It is also helpful in determining which patterns are suitable to either the J2EE or .NET platforms with examples in C# and Java, helping to appreciate patterns that are actually workarounds for limitations in the respective platforms.

If you're experienced in building or designing enterprise systems, there's not much here you won't know already so there might not be any great revelations. And currently, pattern bashing is becoming a popular past-time. But that doesn't take away from the point that this is one of the best written, and best organized books on the application of design patterns. It's probably the best book written on n-tiered application design.

Some places where the book fell down for me:

  • As mentioned a large number of the patterns present are there in order to let developers work effectively with databases, over a third perhaps. If you want to control the risks of implementing business logic on top of a database, this is the book to start with, but the broader question, when and whether to use a database at all, is not asked.

  • I would have preferred to see some messaging patterns than the lightweight treatment on concurrency. Messaging is on the rise as an integration tool. He does say that messaging patterns were deliberately excluded, so perhaps we can look forward to a future book focusing on them.

  • The Front Controller pattern, despite being received wisdom these days, may well be the antipattern for web development, if not used judiciously. Designs based on decorators (and Fowler does mention that possibility), but other options such as state machines, or even aspects aren't considered.

  • With a REST hat on, I'm not so sure about assertions that state is best left on the server in a client-server and web applications. Client sided state is mentioned, but is limited to cookies and some treatment of URLs. I've commented on this assertion before, but ultimately it falls to those of us who feel REST has a value proposition to produce an argument as to why centralizing state is a problem, especially in light of the fact that the web does not function according to REST advocacy in this area.

February 23, 2003 05:40 PM


Trackback Pings

TrackBack URL for this entry:

Listed below are links to weblogs that reference review: Patterns of Enterprise Application Architecture:

» Book: Patterns of Enterprise Application Architecture from TheArchitect.co.uk - Jorgen Thelin's weblog
Bill de hra provides a review of Martin Fowler's latest book Patterns of Enterprise Application Architecture Patterns, Enterprises and Architectures, oh my! But the most important words on the cover are "Martin Fowler". He has already written three fi... [Read More]

Tracked on February 24, 2003 05:14 PM