Patterns of Enterprise Application Architecture

27 July 2006 .NET design patterns

While a big fan of patterns I found the original Gang of Four (GoF) book a little dry and so had left the pattern books alone until Martin Fowler’s Patterns of Enterprise Application Architecture (PEAA), got referenced so many times on-line I gave in and purchased a copy. I’m glad I did – even if the examples are mostly in Java with the very occasional one in C#.

The patterns in the original GoF were really about the interactions between the objects themselves and whilst PEAA has some object-to-object interactions it concentrates on problems encountered in “Enterprise Applications”. This includes database mappings, transactions, web pages and concurrency.

The first half of the book provides a readable narrative and discussion of the various patterns with recommendations for when to use each and when to avoid. Part two explains each pattern in detail providing an essential reference to the patterns themselves. This mix of half-narrative and half-reference works very well and is certainly something other programming books would do well to steal.

As somebody who has been writing ‘Enterprise’ applications for some time it is interesting to see many of the problems described in neutral terms as well as the road-not-travelled alternatives and a rationale for their existence. Even if you came up with something similar yourself (and I’m sure you’ll find a few) giving it a meaningful common name makes life easier when discussing the solution with others.

A fair chunk of the book covers object-relational mapping (ORM) and it addresses most all the issues including whether to go full domain model/data mapper, active record, record set as well as the more intricate issues such as lazy loading, locking, identity map and approaches for how many tables to use for a given object.

There are a couple of issues I have with some of the patterns that don’t seem to be addressed so I’ll throw them out here:

Identity Map

The identify map’s description is

“Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them.”

There are two problems here;

  1. Objects become stale as other users perform updates that your browser/user can never see until your session terminates and thus looses your map. “Log out to see changes” is not acceptable.
  2. Resource consumption is heavy as your identity map effectively holds every object loaded in memory regardless of whether it’s used any more. Those objects may reference other objects too – combine this with a web server and you’re looking at a recipe for disaster as resources dry up.

One approach would be use develop your map using some form of weak reference mechanism. This would mean that once your code looses the last reference the object will be eligible for garbage collection and subsequent reloading from the database. This effectively kills off the secondary role as a cache but better than a web site running out of memory showing lots of old data.

Money

Martin puts forward his discussion of the Money class and while the rounding is useful in my experience a monetary amount and a currency isn’t much use without some way of getting an exchange rate to the base currency.

Lazy Load

The samples Martin provides here are not thread safe and you could easily find yourself with two different objects where you expect one. For a section on lazy loading for enterprise apps not having a double-check lock is a bit sloppy. To correct the sample on page 203 would be (I’ve also converted it to C# 2.0);

public List<Products> GetProducts() {
  if (products == null)
    lock(this)
      if (products == null)
        products = Product.FindForSupplier(GetID());
  return products;
}

Overall a very good book – I really need to get to grips with the patterns Foreign Key Mapping and Class Table Inheritance now.

[)amien

0 responses

  1.