One way to improve as a software designer and developer is to read books. Another way is to discuss with peers. And why not discuss with peers about books? So, first of a hopefully long series, I present here my impressions about one of the books I recently read: the book is Patterns of Enterprise Application Architecture by Martin Fowler.
I have two other books from the same author, Refactoring and Analysis Patterns: in short, I view those three books as connected, in the sense that Refactoring codifies the mechanisms of code transformations (the realization), Analysis Patterns codifies the modeling of systems (the design), and PoEAA covers the middle ground between the design and the realization. Analysis Patterns has been, and continues to be, very useful in my daily job, in one situation it has actually given the necessary background for a whole project.
I got the distinct feeling that PoEAA is targeted to junior programmers in need of a broad overview to the world of enterprise applications, or to senior-level people that have never been exposed to this world. The book does a very good job at that, but experienced enterprise application developers will be a little disappointed (“been there, done that”) to discover that probably 85% of the mentioned patterns are already in their toolbox.
Some of the book’s good points:
- distributing systems (simply don’t)
- Identity Field (216) contains a nice and short treatment of the choice of database primary keys, meaningless or meaningful, simple or composite, table-unique vs. hierarchy-unique vs. database-unique. Again, nothing that moderately experienced people don’t know, but expressed in clear terms and commendable compactness
- the Money base patterns (especially the discussion on rounding) should be taken to heart by ALL programmers, designers, architects, whomever uses or develops software that handles monetary assets
Some of the book’s bad points:
- the discussion of trasaction isolation levels: the recommendation of the serializable transaction level probably means that the author very rarely had the chance to use a good RDBMS, or that he feels that the readers will rarely have that chance. “Good RDBMS” in this context means a RDBMS that enforces the I in ACID without forcing the programmer to overkill measures as serializable
- the desire to avoid as many trips to the database as possible: again, this could be the result of too many bad RDBMS products that the author has used. Such fear of the database is sadly not uncommon in the Java programming community, and is a serious burden to the development of scalable enterprise applications.
Some of the book’s so-so points:
- Template View (350), about conditional display of data: I think that even the presentation layer of an application is logic (display logic, if you want) and so it should be handled as close as possible to the presentation components, in this case the page. The helper object should carry out program logic as is correctly pointed out on page 354.
Furthermore, on pages 356/357 there’s the capital sin of HTML code in a helper class: if one wants to “mix program logic and display logic” then this is the worst possible way of doing it. Try having a graphic designer recompile the helper class… The sin is partially condoned by mentioning that the best alternative is a specialized tag.