The Last Word in Patterns

Software patterns have their roots in architecture. In 1978, Christopher Alexander published a book called A Pattern Language: Towns, Buildings, Construction about the patterns he’d discovered designing buildings [ Alexander78 ]. A pattern can be thought of as a tried and tested way of doing something which can be applied in different contexts. Think about how the Observer or Visitor pattern is implemented across languages such as Java, Ruby and JavaScript, where the different language idioms dictate slightly different implementations of the same basic pattern.

Software patterns became popular with the publishing of the Gang of Four book, Design patterns: elements of reusable object-oriented software [ GoF94 ]. It contains a number of patterns, most of which every developer should know, even if it’s to know to avoid the likes of Singleton . However, these aren’t the only patterns! Indeed, patterns are not created, they are discovered and documented. Whole conferences [ Europlop ] are dedicated to software patterns, where delegates are encouraged to bring their pattern write-ups for appraisal by their peers and the experts.

When I joined ACCU in 2000, I was encouraged by another member to write for the group’s magazine, but I didn’t think I’d have anything to contribute that someone hadn’t already thought of and written about. As I gained experience, I found I had quite a lot to write about and to challenge.

In the same way, you’d have thought that 23 years after the Gang of Four book most, if not all, of the software patterns had been discovered and documented. Of course, they haven’t and I believed, from checking with industry experts, that what I’m calling the Single CrUD Transaction pattern, although used by many, hadn’t been written up anywhere publicly. However, after submitting the pattern to Overload for review, it was pointed out that it is part of the Foreign Key Mapping pattern as written up by Martin Fowler [ Fowler02 ]. I’ve just gone into a little more detail.

Name: Single CrUD Transaction

Intent

To create, update and delete items in a datastore within a single transaction.

Problem

Sometimes it’s necessary to create, update and delete items in a datastore in a single transaction. Traditional web applications support create, update and delete in separate transactions and require the page to be reloaded between each action.

Modern web applications allow the items of a list to be created, updated and deleted in a browser without any interaction with the server or the underlying datastore. Therefore when the list is sent to the server side it must determine which items are new, which already exist and must be updated and which have been removed from the list and must be deleted.

One simple solution is to delete all of the items from the datastore and simply replace them with the list of line items passed from the browser to the server. There are at least two potential drawbacks with this approach:

• If the datastore (such as a relational database) uses unique, numerical ids to identify each item in the list, the size of the ids can become very big, very quickly.
• If the datastore (such as a relational database) has other data which references the ids of the items in the list, the items cannot be deleted without breaking the referential integrity.

Solution

The Single CrUD Transaction pattern gets around these drawbacks by performing three operations within a single transaction:

• Delete all of the list items from the datastore whose ids are not in the list passed from the browser to the server.
• Update each of the items in the datastore whose ids match ids in the list passed from the browser to the server.
• Create new items in the datastore for each item in the list passed from the browser to the server which do not yet have ids.

Each action is executed within a single transaction so that if any individual action fails the list is returned to its original state.

Applicability

Use the Single CrUD Transaction pattern when:

• Datastores cannot have new items added, existing items updated and/or items removed in separate transactions.
• Creating new ids for each item in the list each time the datastore is modified is expensive or cumbersome.
• Removing all the items of a list from a datastore and recreating the list in the datastore breaks referential integrity.

Advantages and disadvantages

• Advantage: Entire update happens within a single transaction.
• Disadvantage: Three separate calls to the datastore within a single transaction.

References

[Alexander78] Christopher Alexander, 1978, A Pattern Language: Towns, Buildings, Construction , OUP USA (ISBN-13: 978-0195019193)

[Europlop] EuropPLoP (European Conference on Pattern Languages of Programs), http://www.europlop.net/

[Fowler02] Martin Fowler, 2002, Patterns of Enterprise Application Architecture , Addison Wesley, (ISBN-13: 978-0321127426)

[GoF94] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design patterns: elements of reusable object-oriented software , 1994, (ISBN-13: 978-0201633610)