Patterns of Enterprise Application Architecture 94
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:
- 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.
Just Started but.... (Score:3, Informative)
So. Cal. study group going through this book now (Score:5, Informative)
http://groups.yahoo.com/group/ocpatterns/ [yahoo.com]
Re:So. Cal. study group going through this book no (Score:2)
Re:So. Cal. study group going through this book no (Score:2)
Nylon bookmark? (Score:5, Funny)
Review is as brief as the code "samples" (Score:5, Insightful)
Re:Review is as brief as the code "samples" (Score:5, Informative)
Re:Review is as brief as the code "samples" (Score:3, Informative)
Re:Review is as brief as the code "samples" (Score:2)
No that's fine, it was basically what I was asking for. It is more to give me a sense of what "level" the book was truely at. I realize that even with these two examples that you would have gotten a lot of grief from people who would not agree with his conclusions (you know what they say about opinions). Anyway, given your examples I can make a better judgement as to whether or not it's worth my time to investigate further.
Talk about a multi-talented author! (Score:1)
http://www.bbc.co.uk/eastenders/char
Looks good... (Score:5, Informative)
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.
Re:Looks good... (Score:5, Informative)
Fowler's book got a Productivity Award at this year's Jolts -- only reason he didn't get the Jolt, IMHO (OK, not so humble, I was one of the judges), is that Bob Martin's book was a little more fun to read and a little more generally applicable. (That one, BTW, is Agile Software Development: Principles, Patterns, and Practices).
I can highly recommend either book.
Martin Fowler Books (Score:5, Informative)
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 [berteig.org] for software developers, architects, project managers, executives, etc.
Re:Martin Fowler Books (Score:3, Informative)
I have to second your recommendation of Refactoring. I feel the same way about it that I do about Design Patterns. Nearly everything in it is obvious ... while you are reading it. Those two books are references for the details that are easy to forget. Refactoring also builds more complex refactorings upon the base of the simpler ones. As that started to happen partway through the book, I
How does it compare (Score:4, Interesting)
I did notice that Fowlers book has code examples in Java, but I didn't find that code was important in describing patterns.
Re:How does it compare (Score:2)
Re:How does it compare (Score:1)
Re:How does it compare (Score:2)
Incidentally, before reading Fowler's book I was a proponent of EJB, however he offers some good critiques of EJB in the book.
did you expect anything less.. (Score:2, Interesting)
Typos (Score:5, Informative)
Re:Typos (Score:2, Informative)
Re:Typos (Score:2, Informative)
Despite the many typos, I think this is an excellent book and I would highly recommend it to anyone architecting or designing enterprise applications.
His definition of an enterprise application is based more on examples and characteristics tha
Re:Typos (Score:2)
Also, although I write a lot of server side code, I dont have so many issues with data-binding as he has. This is very much the 'design patterns for enterprise apps that talk to databases', not 'design patterns for high availability server-side applications' in general.
The ultimate enterprise pattern (Score:5, Funny)
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)
Re:Performance improvement (Score:2, Insightful)
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)
Re:Performance improvement (Score:1, Insightful)
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.
Re:The ultimate enterprise pattern (Score:1)
6) ???
7) Profit !
8) Go to 1)
Re:The ultimate enterprise pattern (Score:2)
Your ultimate pattern is both funny and sad, because it is so true in many people's experiences.
I wonder if this is another reason why so many projects run themselves into the ground in spite of all the warning signs. For a project that experiences leadership turnover 80% of the way through, the money-holders think, "Well, turnover is a risk and costs money and time, so here's more money and time to get back up to speed."
The patterns are available at the author's website (Score:5, Informative)
wasn't he on Little House on the Prairie? (Score:1)
Re:Smells Fishy (Score:1)
Re:Smells Fishy (Score:2)
Re:Smells Fishy (Score:2)
The language is irrelevant, therefore it is the $'s that solidify the decision.
On the contrary, I think (Score:1)
Re:Smells Fishy (Score:2)
Re:Smells Fishy (Score:1)
One common theme... (Score:2, Interesting)
I would recommend this book to anybody at least for the sake of having a common
"Enterprise" I'm sick of this word (Score:1)
Re:"Enterprise" I'm sick of this word (Score:1)
Re:"Enterprise" I'm sick of this word (Score:1, Interesting)
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
Re:"Enterprise" I'm sick of this word (Score:4, Insightful)
Business software is specific to a task, not the size of the tsck.
Example:
A database that can handle 100,000 transactions an hour, with 99.999 up time is 'enterprise' level.
an application that tells you what is in your warehouse, business software. If that same software was called enterprise, you would expected it to have 99.999 uptime, and track many thousands, if not millions, of pieces of inventory scattered in warehouses around the globe.
this is why I laugh when Microsoft calls SQLserver 'Enterprse ready'. it is not.
Re:"Enterprise" I'm sick of this word (Score:2)
Agreed. However, don't forget that it and most Microsoft software aren't even ready for the small business.
Think about how many businesses are now trapped by quickly implemented Access databases and Excel macros, for example. They not only get blocked from accessing their own data without Microsoft's helping hand, but they also face annual upgrade dilemmas by Microsoft's marketing and sales departments. Microsoft's strateg
"enterprise" and "patterns" are BOTH overhyped (Score:2, Interesting)
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 mult
Great book, sad day (Score:1)
Re:Great book, sad day (Score:2)
So why have all OODBMS attempts died. Was it because the world wasnt ready (and are they now), or is it because data in RDBMS have better flexibility of re-use?
Re:Great book, sad day (Score:2)
Re:Great book, sad day (Score:2)
XML databases may be the answer. Also, JDO will bind to a OODBMS under the cover -your app doesnt care, but the whole thing just works better. Compare that with the entire Enterprise Java Bean persistence story
Re:Great book, sad day (Score:1)
IMO any product that needs full time admin & tuning is a failure in TCO terms.
Compare this to the use of full-time operators for administration and tuning on mainframes in a recent article: Mainframe Operators Needed [slashdot.org]. The large companies using and buying mainframes would seem to approve of that particular TCO.
Re:Great book, sad day (Score:2)
our philosophy on server-apps was 'a box that works so well, you forget where it lives'; I think novell were the first people to pull that off in products.
Re:Great book, sad day (Score:1)
In other words, he basically explains why you can't just "whip up" a web app in perl that will work for a 10,000 user system that uses 5,000 datapoints with some data having 100 different business logic cases between.
Storing an object may sound like a very black and white thing, but in an enterprise context, it's all about the relationships and the logic and if you don't fol
Re:Great book, sad day (Score:1)
Sure you can. Just tap into a big relational database. That is one of the beautiful things about RDBMS: you can add a new "task" or "micro-app" to it just using relational queries (and maybe some transaction markers). It does not matter whether the DB contains 100 records or 1 billion, you
Re:Great book, sad day (Score:1)
Why do we have to make it hard on ourselves, surely creating code in an object oriented programming language and storing the data in an object oriented database
Re:Great book, sad day (Score:2, Informative)
We have powerful OO programming languages but we have to translate objects to rows of data to store in a table!
OO programming languages allow programmers to create vast, ad-hoc conglomerations of data, then hand-write ad-hoc code to traverse, read and manipulate those data structures.
The relational data model makes the relationships between different data explicit, and exposes those relationships in such a way that other programs can write all the code to traverse, read and manipulate them. This is
Re:Great book, sad day (Score:2, Informative)
OODBM's have some serious drawbacks that seem to re-expose the same problems that pre-relational databases had.
Relational has the concept of "table" that is a higher-level structure than a mere "record". OO lacks a decent higher-level structure than a record (class/object). (Trees and GOF patterns have been tr
Re:Great book, sad day (Score:2)
fact of the matter is, relational theory is mathematically sound, complete, etc. sql is not. it is
[snip: rant about wrapping tuple data in objects because it's "cool"]
i would like a good set of OO principles for database
Re:Great book, sad day (Score:1)
Well, I agree that SQL is not the perfect relational query language, but that is kind of a side topic. Even imperfect relational stuff has some nice benefits.
(because of specialization / generalization by constraint: is a circle an ellipse, the other way around, or neither?)
The long-standing circle/ellipse debates are simply another way to say that "abstractions are relative". Inheritence tends to assume the
Re:Great book, sad day (Score:1)
Re:Great book, sad day (Score:1)
What do you mean by the cost?
You've got pretty much too choices in object-relational mapping: write a custom mapper or suck wind with a framework. Hopefully we'll find some better options soon.
I am a bit skeptical that relational and OO will ever fully get along. They are just too different in their *root* philosophy. Relational is *tightly* based on the concept of a table, while OO is not. Tables incur ce
Re:Great book, sad day (Score:1)
Re:Great book, sad day (Score:1)
Are you suggesting roll-your-own joins (not "joints") are faster? Most performance problems with joins can be traced to bad schema design in my observation.
And especially if you have hierarchical data, which the relational model isn't too good at.
Well, that is debatable. Most uses of large hierarchies are improper IMO anyhow. Oracle has added hierarchical extensions to SQL, I would note.
Sounds like a good strategy re: code (Score:4, Interesting)
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.
Re:Sounds like a good strategy re: code (Score:2)
You can tell by the bindings, and the amount of yellow stickies poking out of them.
Except for the K&R book, the standard for use is still the number of coffee rings on the cover.
Re:Sounds like a good strategy re: code (Score:1)
Good Stuff (Score:5, Interesting)
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.
Re:Good Stuff (Score:1)
Re:Good Stuff (Score:1)
Here's a pattern that doesn't get mentioned enough:
Cranky old people bitch about how much better things used to be, then they give birth to young people who grow up to be cranky old people who...
Great book (Score:2, Interesting)
IMO, this book is a must-have for writing enterprise apps.
Comparison (Score:1)
Choices (Score:1)
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