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/
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.
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.
Try the book's site for a complete list of patterns, with diagrams and descriptions: http://www.martinfowler.com/eaaCatalog/
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.
http://www.martinfowler.com/eaaCatalog/
Okay, these may not be really impressive, but the ideas were fairly new to me.
-- Solaris Central - http://w
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.
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 tried for this, but so far have big flaws. See link).
The higher level structure (table) allows a powerful and compact math-like reasoning, aggregation, and grokkability. There has yet to be a Dr. Codd of "object math", and so one has to deal with objects one-by-one (AKA "navigational") so far in history.
I agree this may all be subjective, but I like the relational model, it sings to me (even though vendors often butcher it). In my head it is more powerful and compact than what the OO people have. OO is too many trees without clean, consistent forest management techniques. Relational is mostly forest math and OO is mostly tree math.
(For more details on this opinion: http://www.geocities.com/tablizer/core1.htm)
Table-ized A.I.
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 the whole point of query languages; all the work of traversing the data structures, extracting fields and building temporary structures is done for you.
Note that it is possible to concisely specify certain types of hierarchical traversal, and have code generated for you. This is what XPath does, for example. But the relational model allows automation just about everywhere.
In addition, because all the data and relationships are exposed, the RDBMS can write code to enforce data consistency rules. RDBMS declarative rules can span datasets in ways that would require custom code in a normal programming language. In fact, if the data and relationships are correctly designed, certain types of inconsistency become impossible; this is what normalization is all about (also known as "Once and Only Once").
The problems are (a) SQL blows chunks as a relational query language, which means you have to use a second language for certain tasks, and (b) the second languages are even less suited to the relational model than SQL. So when people struggle to store their hand-crafted object graphs in a relational database, they blame the database.
Notes (because someone will want to bring these up):
Views provide polymorphism in the relational model. The view acts as a base class, containing a subset of field names (possibly renamed) from any number of datasets. The performance of a view is stricly up to the implementation. If your RDBMS can't update views, it's broken.
It's possible to represent a tree in a relational database by storing the nodes in one dataset, and the parent/child relationships in another dataset. However, this is an inconvenient representation for doing reasoning on. Chris Date has proposed an "EXPLODE" operator that would convert the two-dataset representation into a data-preserving, but larger, flattened representation that the DBMS could work with. (Note that the query engine wouldn't have to run a full EXPLODE on every query; behind the scenes it can do whatever tree walking it needs to for efficiency.