Slashdot Mirror
Patterns of Enterprise Application Architecture
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:
- 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.
- 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.
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.
I have just started reading this book, but so far I have found it to be very interesting as this is my first venture into the world of patterns. I found his discussion of "Business Ill-logic" very appropriate to most of the systems I have worked on.
I am so creative, look at my cry for attention in my sig.
We have a design patterns study group that meets in Santa Ana twice a month to study this book. If anybody in the SoCal/Orange County area of California wish to join us please visit our website for more information.
http://groups.yahoo.com/group/ocpatterns/
BTW, my book didn't come with a nylon bookmark. That would have been useful. My GoF patterns book has a book marker. I think the use of embedded book markers and hard-bound covers are an attempt to represent the book as more cannonical, a biblical tech reference of sorts. Quite a few of the Addison Wesley books seem to follow this model, like GoF, as well as my 3 volume "TCP/IP Ilustrated" books.
Hmm, this review lacks meat. The book is about patterns and the reviewer says the author has good ones. Well how about some examples of these patterns, esp one or two that are non trivial (and thus make having a book like this worthwhile). Since this book is obviously geared towards those with a fairly good level of experience/knowledge, that audience would want to see some real meat in the review, vs "it has good stuff, trust me". And no, a book that states "separate presentation and domain logic" does not automatically qualify it as a good book as this is "Programming 101" stuff.
How does he find time to do all this and appear in Eastenders?a cters/martin_ f_biog.shtml
http://www.bbc.co.uk/eastenders/char
I bought this last weekend, and it looks good. I'm seeing a lot of patterns I'd noticed, and he's brought up some that I can look back and say "Yeah, we did that - badly...."
He does a good job talking about the pragmatic decisions that real architects and senior developers make, as opposed to the idealists and purists. The OO purists may want each attribute's "get" to be a separate call (and maybe cause that call to traverse the network), but the Remote Facade builds much more efficient interfaces. I've been building Domain Models and Foreign Key Mappings for years, and calling them by terms close to those.
One of the things all these Patterns books have done is define a common terminology for concepts we've all known about. For that, if nothing else, we owe Fowler our thanks.
I love vegetarians - some of my favorite foods are vegetarians.
WTF does this have to do with the book? Keep your political discussions to a thread more suited for it.
I am in the process of reading PoEAA - I agree wholeheartedly with the review. As a professional software architect and mentor, I often recommend Fowler's books. Another great one is "Refactoring" which presents a systematic method for improving the design of existing code.
I have a list of excellent resources for software developers, architects, project managers, executives, etc.
Helping with organizational effectiveness is our job.
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.
than a 10/10 for an Addison Wesley book? AW is simply the best technical book publisher out there.
Maybe I was the only one who noticed it, but the book is riddled with typos and grammatical mistakes that really make the information hard to absorb. Other than that, the book is very good and I recommend it highly.
1) Purchase an enterprise pattern book
2) Skim it and learn the jargon
3) Repeat jargon to anyone who will listen until the powers that be put you in charge of a really large project
4) Keep promising success until 80% of the effort is expanded
5) Change jobs
6) Go to 1)
You will have to pry my proprietary software $$$ from my cold dead hands!
http://www.martinfowler.com/eaaCatalog/
Minor performance optimization:
Since you have already read an enterprise pattern book, you already know the jargon. The optimized last steps are:
4) Keep promising success until 90% of the effort is expended
5) change jobs
6) Go to 3)
I put my application in to serve on the Enterprise, but was kicked out of Starfleet Academy during my senior year for cheating.
Seems my instructors didn't like my solution to the Kobiyashi Maru. I hax0red the computer so I could win.
I heard that a similar case happened with a boy from Kansas or some such place, but he received preferential treatment due the the fact that they thought that he was retarded, what with his stilted speech and all.
That's a great idea for a group. May I ask how many people usually show up at the meetings? Are there other groups like this outside of Santa Ana?
Sex - Find It
The key is that, unfortunately, you must keep learning new jargon and thus buy new books.
So if you stand up now and say: "model-view-controller" no one will give you the time of day.
The key to jargon is that it must sound compelling but unknown to the audience.
"Code examples are given in Java and C# where most appropriate for the given pattern, however most examples use Java."
C# huh. Seems a bit slanted to me. And I really enjoyed his refactoring book and talks at the Software Developers Conference in 2001.
Man, first we lose Stanley Lippman (co-creator of C++) to the dark one, now the great Martin Fowler. Somebodys getting a big kick back for this I'm sure.
come on fhqwhgads
You meet twice a month? To study a single book? If it was the Bible (not the K&R edition, the Disciples' one) I might understand...
That was funny as hell.
I heard that Kirk scripted the KM simulator through a hole in a savegame for 007 Nightfire.
I would recommend this book to anybody at least for the sake of having a common jargon to communicate with.
Why has the word "enterprise" replaced the word "business" when talking about computer software? Is it just buzzword compliance, or does it actually convey more information?
It is sad that Martin had to write this book. Only in our industry would we make it complex to store objects. Why don't the big RDBMS software manufacturers take some of their profits and create a true OODBMS so we don't have to do this crap.
or something?
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
Hey, Perlers! Over here! Perl Design Patterns =)~
Or get the up-to-the-minute version straight from CVS but less pretty
Are you attempting satire? If so, it wasn't very successful. Rather, you succeeded in sounding completely ignorant.
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.
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.
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.
I am a long-time fan of Fowler's book "Analysis Patterns", it has become a trusty fellow. Can anyone tell me how this book measures up to Analysis Patterns?
C# effectively is Java, with a few minor changes here and there. A Java coder that reads this book can claim to know C#, and has a foot in the .NET door.
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
I agree with most of the posters - this is a very good book and really articulates many of the learnings I've had over the past too-many years.
Combining this with Hays' Data Model Patterns is a good starting point on any bookshelf.
what do you mean?
I think that's racist - no, imperialist - of you.
My only beef with the book is that he didn't go further into why one pattern would be better than another in a given situation. For someone new to patterns, it can be like a chinese buffet with 100 different dishes on it - how to choose from among so many tasty items?
Of course, every situation is different. But there are common tasks (I won't use the phrase meta-patterns) that programmers do - write a e-commerce shopping site with shopping-cart, deal with nested objects like invoice-lineitem, etc. And I would have liked to have seen an example of when a certain pattern would be useful.
Maybe in a forthcoming companion volume?
Chip H.