Transaction Script Pattern
Transaction Script (TS) is the simplest domain logic pattern we can find. It needs less work to implement than other domain logic patterns and therefore it’s perfect fit for smaller applications that doesn’t need big architecture behind them. This posting focuses on TS pattern by illustrating and analysing it. Also some good hints for implementation are provided.
Definition
Transaction Script organizes business logic by procedures where each procedure handles a single request from the presentation.
pg. 110, Patterns of Enterprise Applications Architecture by Martin Fowler
Example
Imagine application that provides some functionalities:
- load orders to deliver,
- generate invoices,
- calculate bonuses for customers.
These functionalities can be handled as two transactions: generate invoices, calculate bonuses. We cań create classes to handle invoice generating and bonus calculation but we can also go with one class that provides both methods. It’s up to you to decide which is better for you.
class InvoiceGenerator
{
public void GenerateInvoices()
{
load orders to deliver
iterate through orders
generate invoice
mark them ready to deliver
}
}
This example uses one class for all operations. If you have many operations then use multiple classes to organize code better.
Where I use TS?
I have used TS mainly in small applications where I really don’t want to apply any bigger architecture. TS will save you a lot of time when applied in correct context. Some applications where I used TS are:
- Estonian ID-card based door lock control – Windows service and simple Windows Forms applications that allow to manage users, give permissions for opening doors and see who and when opened the door. It may sound like big application but the actual complexity lies in hardware and the software I wrote is actually very simple.
- Jira importer – my company uses small service that imports work logs and tasks from Jira to our main database where programming work, sales and billing meet. Getting data from Jira can be tricky but still this service is simple enough to avoid more complex patterns.
On both cases I got simple classes that provide some functionalities needed by applications and it took less time than implementing full domain model by example.
Tips
- TS works well for small applications that doesn’t implement any complex logic,
- When used in bigger applications TS has problems like code and functionalities duplication between procedures. If you see application growing then switch to some other domain logic pattern that is better fit for your application.
- It’s not easy usually to refactor TS to other domain logic patterns as other patterns deal more or less with classes that represent some business entity.
- In TS you can use different data source patterns to access and manipulate data. In my door lock control system I used ADO.NET objects. My Jira importer uses simple Entity Framework classes.
- When building your TS classes you can also apply design patterns to organize code better. Don’t let your TS classes grow to big bad spaghetti code.
- Don’t make TS classes dependent on presentation layer classes because dependencies like these makes it harder to share those classes between applications and also testing of TS classes will be very hard this way.
Wrapping up
TS is simple and lightweight domain logic pattern that is perfect fit for smaller applications that do nothing complex. It is possible to gather all operations together to one class but if you have many operations then it’s better to use more than one class for operations. If you see your application growing bigger and more complex then switch quickly to some other domain logic pattern that fits your needs better.
