The Transaction Script Pattern

I recently called upon the services of the Transaction Script pattern to organise new business logic for my current software project. I had a bunch of procedural and database-centric logic to implement and needed a way to structure it so that it would be maintainable. I appear to have chosen a reasonable solution, because this pattern has helped me create a simple design that, so far, has proved easy to work with. I also ended up with code that is more readable than I could have hoped for. Go me!

The Transaction Script pattern is as simple as they come. It organizes multi-step business logic into discrete procedures with each procedure implemented either by a single method, or by a group of methods within a dedicated class. The pattern takes its name from the fact that most often a procedure will be executed within the scope of a single database transaction.

Martin Fowler presents the Transaction Script pattern in his book Patterns of Enterprise Application Architecture and it is also catalogued on his site.

In adopting the pattern for my own code, I opted to give each procedure its own class, a la the Command pattern / Object Method refactoring. I think that this decision has been central to my success with the Transaction Script pattern.

I found that partitioning the procedures into their own dedicated classes made for rapid progress, because it facilitated ‘coding by intention’ and refactoring. I was able to decompose each procedure into a set of small and cohesive methods that found a natural home within the class implementing that procedure. These methods could thus share state via instance variables, which removed the need pass data around. Where logic was duplicated across procedures, I found that I was able to extract the duplicated code into a method and pull it up to the base class.

I’m very happy with how it’s playing out so far, but it will be interesting to see the long-term maintainability of this design.

WTF?

If you're a Software Developer, or you work with developers, then you'll probably get a kick out of The Daily WTF, a look at "Curious Perversions in Information Technology". I came across the site a few weeks back and became hooked. I read it every day with my morning coffee (I find it's best not to attempt to drink the coffee until after you've read the post).

A Blog is Born

Well I've done it now! I've created a blog. A chain of events has been set in motion that can lead to only one of two outcomes. Either: a) I'll become famous and have riches beyond measure, or, b) I'll experience abject public humiliation and be forced to slink back into the shadows. Okay, so maybe these aren't the only possible outcomes.

So why have I to created this blog? Before embarking on this project, I did some brief Googling into motivations for blogging. I wanted to understand why I was attracted to the idea of writing a blog. I discovered that I fall squarely into the 'Blog as Muse' camp, which sees blogging as 'thinking' through 'writing'. I look at blogging as an opportunity for me to stop and think on a regular basis. Hopefully, sometime in the future I'll be able to look back at my collected musings and see how my thinking has evolved.

What will I be writing about? Well, I'm a Software Developer and I tend to think quite a bit about the practice of my trade. For the last few years I've been learning about Agile Software development - mostly in the form of Extreme Programming (XP) - and how Agile techniques can improve the chances of success on software development projects. I expect this blog will have a fair amount to say on my experiences of software development and agile methods.

No, wait! Come back! I'll throw in some other stuff, if you promise to hang around.