I’ve been involved in looking at a lot of middle ware “Transaction Script” style code that sent a few alarms bells off in my mind. This pattern of code is explained in Martin Fowler’s book, Patterns of Enterprise Application Architecture.
As I’ve been coming from a lot of research in to Agile programming practices, my main focus is testable code. From that, is how clean the code has to be to be testable. The other bigger values of clean code is of course, one’s ability to learn an API or maintain it – navigation.
With that in mind, “Transaction Script” certainly doesn’t fit nicely with the new Agile principles and practices I now have. The disadvantages I see with this style of programming is quite alarming to me. I’ll be quick and summarize my thoughts:
- Huge “global” type functions make it very difficult to test and inject mocks – TDD and TAD becomes difficult.
- OOD/OOP is usually out the window, as the style is more procedural.
- Code duplication due to the repeated nature of logic throughout other transaction scripts.
- Low class cohesion – big weighty functions carry all their state required to perform the one operation.
- Anaemic domain model – “Transaction Script” is usually accompanied by DTO’s.
It’s not all bad however. Anyone can start a function and grow it with endless amounts of logic in the fashion “Do this, do that, do this, do that, done.”. It definitely is quick development in the short term and not hard to simply to come up with CRUD style operations over a set of DTO’s. This highlights that Transaction Script favours business code that doesn’t carry a lot of logic – load an object, update an object, save an object. It really shines if most of the code you have to write is simply that. Beware though, the parts of a system that start requiring more logic than usual will soon give birth to a “Tar Ball Object” – horrendously large classes.