Transaction script = Antipattern

[Hall of Famer]

I've been reading Martin Fowler's book about enterprise architecture patterns for a while now. From what I find about Transaction script, it is not object-oriented at all. Its basically procedural code despite the fact that it may use objects in every line of its code.This code below, for instance, is purely procedural despite the fact that it works with objects in every line:

<?php
/* Execute a prepared statement by binding PHP variables */
$calories = 150;
$colour = 'red';
$sth = $dbh->prepare('SELECT name, colour, calories
    FROM fruit
    WHERE calories < :calories AND colour = :colour');
$sth->bindParam(':calories', $calories, PDO::PARAM_INT);
$sth->bindParam(':colour', $colour, PDO::PARAM_STR, 12);
$sth->execute();
?>

Yeah this is not a complete picture of Transaction script pattern, and you can actually wrap up the code inside a transaction object's method(if you care to design one such object for each transaction). Still, this does not change the fact that the approach as a whole is procedural, its not object oriented. For this reason, transaction script is an anti-pattern in the object oriented world. Its usage should be limited to really simple/small script and for newbies to get used to database extensions such as PDO and MySQLi classes.

 

The better solution is to use a domain model instead, coupled with a data mapper with unit of work/identity map/lazy load/query object and such. OOP is mostly about OOA(object oriented analysis) and OOD(object oriented design), which fits well with domain model and data mapper. To create object oriented script, we will need to take this necessary design approach. Fortunately most large application frameworks do have domain models and data mapper, which makes object oriented design much easier and less time consuming. Here is an example of Domain model with Data mapper, as illustrated by Anthony Ferrara. Its just a small fragment of the client code, with the detail of implementation hidden inside the domain object and mapper. It is truly object oriented:

$mapper = new PersonDataMapper(new MySQLi(...));
$people = $mapper->getAll();

Using transaction script, however, the code is actually procedural in disguise. The usage of object operator -> does not make it professional object oriented code:

$m = new MySQLi(...);
$res = $m->query($query);
$results = array();
while ($row = $m->fetch_assoc($res)) {
    $results[] = $row;
}

So what do you think? Should professional coders all stop using transaction script if they havent, since its actually an anti-pattern? Perhaps there are times when people are comfortable with using an anti-pattern, but I doubt there is any justification for at least large softwares to apply it.

Edited April 22, 2013 by Hall of Famer

[requinix]

The fact that you aren't using one pattern does not make the one you are using an anti-pattern.

[ignace]

A pattern becomes an anti-pattern when the disadvantages outweigh the advantages. Just because "IT'S NOT OO" does not make it an anti-pattern. That said show me any OO project and I'll show you procedural coding.

 

TS is a simple pattern to solve simple problems (patterns actually solve problems you know, not just to put buzzwords in your project).

 

A TS can be a function, method, or even a class (Command pattern). A simple example of a TS

 

function bookHotelRoom(Room $room, Guest $guest, PaymentGateway $card) {
  // 1. check room availability
  // 2. calculate rates
  // 3. update the database
}

A simple transaction. A TS is not a good choice when your code is really complex and changes a lot, in these cases it's better to use a Domain Model. Which does not mean that FOR EVERY problem you should create a domain model instead you should put a little thought in your app. design and not just break out the warships to S.W.A.T. a fly.

 

Many people seem to believe that if their code is simple they are not professional programmers which is why the code on many projects is really complex (CS degree required) while their domain is really simple to understand (bubblegum dispenser). Praise yourself when you have been able to solve a problem in a very simple fashion.

 

Read this more detailed article on TS by MF http://www.informit.com/articles/article.aspx?p=1398617

Edited April 22, 2013 by ignace