What is a Transaction Pattern?

Transaction Patterns are patterns which describe user transactions, and are geared towards the structure and behaviour of application components from the user's perspective. They are not the same as design patterns which describe the framework on which applications are built.

Every application is made up of a number of components which may also be known as 'tasks', 'units of work', 'functions', 'modules' or 'transactions' (a user transaction, not a database transaction, although one may involve the other), and each of these transactions does something or other to one or more tables within the application database. A user transaction is always described from the user's point of view, for example "this is what it looks like and this is what it does", and this description does not include references to the design patterns which may be used in its implementation.

Although each transaction is different, after having built a number of transactions it may be possible to spot some similarities between one transaction and another. These similarities can be organised into recurring patterns, but as they are not the same as design patterns they require a completely different vocabulary, one that is based upon transaction patterns. For example, take the following comparison between two transactions:

  • Transaction #1 does something to database table 'A'.
  • Transaction #2 does exactly the same thing, but to database table 'B'.

That phrase "does exactly the same thing" should trigger in your mind that there is something in common between these two transactions, and this commonality can be formed into a pattern, something which is repeatable. Before it is possible to identify a pattern it is first necessary to describe each transaction in terms of the following:

  • Structure - what it looks like, how many elements it contains, how they are positioned and how they are related.
  • Behaviour - what it does, what actions it performs, either automatically or by user selection.
  • Content - what data is acted upon within each element.

A pattern can be described as a particular combination of structure and behaviour, and it can be turned into a working transaction by adding in the missing ingredient which is content. The reason for separating structure from behaviour it is to make it possible for different patterns to share the same structure but to have different behaviour.

For a full list of the transaction patterns that are used in RADICORE please refer to Transaction Patterns for Web Applications.

The Radicore framework has been specifically engineered around these transaction patterns so that complete working transactions can be built very rapidly. Each user transaction consists of the following modules which are based on the Model-View-Controller design pattern:

The term "reusable" means that each of those modules is defined once, and each transaction contains a reference to the central definition instead of carrying around its own local copy. This means that should it be necessary to change the code within any pattern, that change will be automatically inherited by every transaction which is based upon that pattern.

A properly crafted set of transaction patterns can be great time savers - an essential ingredient in a RAD environment:

  • Time is saved when designing the application as all the possible patterns have already been mapped out. It is therefore possible to mould the design to fit these patterns without having to reinvent the wheel.
  • Time is saved when writing program specifications as there is no need to go into detail on the expected structure and behaviour. This is covered simply by identifying the pattern which is to be used, and the content on which it is to be used.
  • Time is saved when writing transactions as there is no need to duplicate the code which deals with the structure and behaviour. This is all provided as part of the pattern. All that has to be done is to identify the content, then add in any specialist business rules into the model component.
  • Time is saved when performing unit testing as the common code within the pattern has already been tested. If a pattern is used 50 times then exhaustive tests need only be performed on one implementation of that pattern, not all 50.
  • Time is saved when writing program documentation as references to the standard pattern will cover the structure and behaviour. The only extra information required is that of the content (the application data and associated business rules).
  • Time is saved when performing global updates as a change can be made to a single pattern. This change is then automatically inherited by all transactions which are based on that pattern.
  • Time is saved by not having to correct inconsistencies which are introduced by different programmers. Transactions written from patterns will all look and behave in a consistent manner, and this removes a source of annoyance from the users.

A more detailed version of this article is available at What are Transaction Patterns?

A complete list of all the Transaction Patterns which are available in the RADICORE framework is available at Transaction Patterns for Web Applications.

Published: 09 April 2006