Slashdot Mirror

← Back to Stories (view on slashdot.org)

Patterns of Enterprise Application Architecture

Posted by timothy on from the puzzle-pieces dept.

Duane Gran contributes this review of Patterns of Enterprise Application Architecture, writing "The title of this book is a mouthful and the author, Martin Fowler, confronts headfirst complex topics of concern to software developers and architects. Fowler is a respected figure in software engineering circles, and his latest book is an attempt to codify best practices he learned in the trenches and through peer relationships. Many of the patterns will resonate with experienced developers, but Fowler's talent explaining abstract concepts will afford even the most grizzled reader many 'aha!' moments." Read on for the rest of Duane's review. Patterns of Enterprise Application Architecture author Martin Fowler pages 560 publisher Addison Wesley Professional rating 10/10 reviewer Duane Gran ISBN 0321127420 summary Excellent analysis of complex problem solving

The book is honest and upfront about grey areas in addition to (nearly) hard and fast rules. Fifty one patterns are described in an organized fashion, grouped by theme. The first section gives an overall narrative tying together the concepts while the remaining 4/5 of the book is devoted to short chapters on each pattern. In this way the book works well on two levels, as a reference and a tutorial. Code examples are given in Java and C# where most appropriate for the given pattern, however most examples use Java.

Much of the book centers around the task of Object-Relational mapping between the in-memory model of an application and the datastore. There are a surprising number of design choices in enterprise systems and I often found myself nodding in agreement with the logic behind the patterns. After establishing that mixing presentation and domain logic is a mistake worthy of horse-whipping, a plethora of smart alternatives are given.

I found this to be one of the more enlightening books I've read, and place it alongside Effective Java and Design Patterns Explained as canonical books for the Java developer. I'm a fan of the O'Reilly Java series, which excels in the HOW-TO category of books, but I've recently taken to the Addison-Wesley publications, which deal less with the nuts and bolts, and for lack of a better word are more like WHY-TO books.

Aside from being an excellent book, I also liked that it is hardbound and includes a bookmark (simple nylon strap from the binding). This is a fitting presentation for such a quality book.

The only complaint I might have is that sometimes the code examples are a tad brief for my taste. The author is fond of declaring a class as follows:

class ArtistMapper ...

From the UML diagrams provided I was often able to conclude that ArtistMapper extends AbstractMapper or that ArtistMapper implements Mapper, but as I read the examples I yearned for completeness. Two guesses come to mind as for this choice:

  1. The author explains that the code examples are meant to facilitate understanding, not to provide boilerplate code. Fowler's appreciation for the complexity of software systems leads him to caution the reader to implement the examples without careful consideration to the context in which they are deployed. Partial code examples forces the reader to fill the gaps, and in the process may think more critically about it.
  2. There is often more than one way to do things, like abstracting an interface in Java. The choice of extending an Abstract class or implementing an interface implies a subtle, but far-reaching, development choice. Similar to the previous point, I think Fowler may want the reader to choose a concrete class implementation appropriate for his or her application.
On the whole, I really enjoyed the book and would recommend it without hesitation to fellow software developers and architects.

You can purchase Patterns of Enterprise Application Architecture from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

8 of 94 comments (clear)

  1. How does it compare by bmongar · · Score: 3, Interesting

    My question is how does it compare to the "gang of 4" Design Patterns book (ISBN 0201633612). It is a fairly complete catalog of patterns.
    I did notice that Fowlers book has code examples in Java, but I didn't find that code was important in describing patterns.

    --
    As x approaches total apathy I couldn't care less.
  2. did you expect anything less.. by tsqlnerd · · Score: 2, Interesting

    than a 10/10 for an Addison Wesley book? AW is simply the best technical book publisher out there.

  3. One common theme... by jkauzlar · · Score: 2, Interesting
    among the reviews on Amazon was that even for an intermediate level web designer, much of the material in this book is not entirely surprising or new. IMHO, I agree with this, but I think the book's contribution is mostly in its catalogue and well-written analysis of EA patterns. The GoF book contained some patterns that seemed almost like magic to me at first, whereas Fowler's patterns are less magic and closer to common sense.

    I would recommend this book to anybody at least for the sake of having a common jargon to communicate with.

  4. Re:"Enterprise" I'm sick of this word by Anonymous Coward · · Score: 1, Interesting

    I think that an enterprise system enables multiple applications to work with eachother.

    An "enterpise" system should have an API/message protocol that enables running applications to talk to each other, yet preserve semantics across the organization.

    It's like comparing desktop apps with ERP systems

  5. Sounds like a good strategy re: code by dmorin · · Score: 3, Interesting
    I know that the value of printed texts, to me, decreased when we started including CDs with every book (or downloads for every magazine). Why? Because when all you're doing is running somebody else's code, usually without even looking at the source, you never get a chance to internalize it. You never have to say "What's this and why does it do that?" other than to answer "Because that's what the author chose to do and it's supposed to work like that." Back in the old days when you actually had to type code in, every line of the source went from print to eyes to brain to fingers. So whether you knew it or not you got a flow for what was going on. And you saw parts that interested you that you could come back to.

    These days code is so big that this is unfeasible. So it seems like Fowler has chosen an interesting strategy -- give you most of it. That way you still have to get into the editor and experience the source, but you don't have to spend days in order to do it. Nice. Learn by doing at its finest.

    --
    www.HearMySoulSpeak.com
  6. Good Stuff by the-dude-man · · Score: 5, Interesting

    Books that will rant on at lenght about the technical details about languages like java and c# are a dime a dozen.What is lacking is good books that solidly illustate the patterns behind object oriented design.

    I think the reviews critisim about using such concepts as extending and implemeting in excess is not warrented, the book is about Objected oriented design, there are other ways to implement these methods, however, implementation of interfaces, and extending other classes, is really *the* object oriented way to solve this problem. Its hardly fair to say that its merly one way to solve the problem. There are many ways to implement the concept of extending another class or implementing an interface, however, these are technical details, and the primary focus of the book is patterns, and design principles, and wich ones work, and wich ones dont.

    Also, the other speaks of the lacking of code samples, agian, this is not a codeing book, the focus here is design, and principles. Therefore, code takes a back seat. The problem with putting code in books, is that you get bogged down by implementation details, wich really goes outside of the scope of what the author is talking about, with short code samples, the point can be convayed. How to implement it in a more complex situation in a particular language is the job of the individual devloper. This book obviously isnt going to get into it, because its about design.

  7. Great book by rbgrn · · Score: 2, Interesting

    I picked this book up last month and read probably 30% of it so far. All I can say is that it is very well done and although I get slightly annoyed that he references other materials without providing more concrete examples, overall the book is very well done and really does provide a good dictionary of patterns as well as comparisons to different patterns with pros and cons for each.

    IMO, this book is a must-have for writing enterprise apps.

  8. "enterprise" and "patterns" are BOTH overhyped by Tablizer · · Score: 2, Interesting

    Both "enterprise" and "patterns" are current "in" buzzwords. I have requested a better definition of "enterprise" multiple times, but have yet to get anything consistent. "Expensive" is about the closest I can get to a consistent definition :-)

    Looking at some of Fowler's other works, I am fairly convinced that he tends to do in application code what would best (IMO) be done using the database. Many of the OO "patterns" are sort of roll-your-own-database techniques. OO Patterns get especially messy for multiple dispatching. Roughly 2/3 of their complexity would be reduced to a compact relational formula if they used relational to its full potential rather than a mere "storage device".

    There is a fundimental philosophical battle between relational thinking and OO's code-centric design. I personally think that the OO side is wrong. More info:

    http://www.geocities.com/tablizer/core1.htm

    http://www.geocities.com/tablizer/whypr.htm

    http://www.geocities.com/tablizer/prpats.htm

    --
    Table-ized A.I.