Najprostszym wzorcem projektowym warstwy biznesowej,  należącym do grupy wzorców proceduralnych jest skrypt transakcji (w skrócie TS – transcaction script). Spójrzmy na diagram UML przedstawiający przykład jego użycia:

Innymi słowy, TS jest zapisem przypadków użycia w naszym systemie. W przypadku systemu sprzedaży oczywistymi przypadki użycia są m.in.: dodanie nowego klienta do bazy, złożenie zamówienia czy pobranie listy produktów. Jak już wspomniałem jest to wzorzec proceduralny a nie obiektowy zatem nie ma żadnej zależności między obiektem biznesowym a klasą TS . Klasa implementująca TS zatem może zawierać zarówno metody związane z produktami jak i z zamówieniami.

W programie możemy zdefiniować dowolną ilość skryptów transakcji – nie ma z góry narzuconej metody podziału.

Jak widzimy wzorzec jest bardzo prosty i składa się wyłącznie z pojedynczych klas. TS to prostu zwykła klasa zawierająca metody wykonujące jakieś operacje oraz często operujące na bazie danych.

Warto również pokazać jak wykorzystać TS w połączeniu z wzorcem polecenie (ang. Command). Szczególnie pożyteczne jest to w małych aplikacjach w których implementacja interfejsu stanowi znaczący procent pracy włożonej w całość systemu. Zacznijmy od diagramu klas:

Kolejne klasy poleceń zawierają logikę zawartą w TS (albo ją po prostu wywołują). W takim przypadku łatwo zaimplementować mechanizm undo \ redo. W większych systemach ciężko użyć powyższej implementacji ale dla prostych aplikacji jest to rozwiązanie bardzo wygodne w użyciu.

Ze względu na proceduralny charakter TS, często dobrym rozwiązaniem jest zaimplementowanie TS jako singleton:

Oczywiście nie będziemy mogli użyć implementacji singleton w przypadku gdy nasz TS nie jest napisany w sposób bezstanowy. Pamiętajmy jednak, że TS wykorzystywany jest w małych systemach w których nie wprowadza się dodatkowej warstwy usług więc powinniśmy implementować zawsze TS bezstanowo (będzie on prawdopodobnie wykorzystywany bezpośrednio jako np. usługa sieciowa).

Na zakończenie krótkie podsumowanie w formie zalet i wad.

Zalety:

1. prosty w implementacji,
2. w przypadku gdy zaimplementujemy go jako polecenia bardzo łatwo wykorzystać wzorzec bezpośrednio w interfejsie,
3. stanowi naturalne przejście z przypadków użycia (zdefiniowanych przez architekta \ analityka) na kod.

Wady:

1. brak reguł mówiących ile tak naprawdę powinno być klas TS. W przyszłości może okazać sie ze lepiej byłoby rozdzielić napisany już TS na dwie osobne klasy,
2. brak jawnego oddzielenia TS od warstwy dostępu do danych. Bardzo łatwo zapomnieć się i umieścić kod należący tak naprawdę do DAL w TS,
3. wzorzec formalnie nie narzuca niezależności od źródła danych – programista musi zadbać o interfejs, który abstrahuje od typu przetwarzanego źródła danych.