CHAPTER 12 ■ ENTERPRISE PATTERNSand feedback messages composed. Business logic is about doing the stuff that needs doing—the true
purpose of the application. Everything else exists just to support these tasks.
In a classic object-oriented application, the business logic layer is often composed of classes that
model the problems that the system aims to address. As you shall see, this is a flexible design decision. It
also requires significant up-front planning.
Let’s begin, then, with the quickest way of getting a system up and running.
Transaction Script
The Transaction Script pattern (Patterns of Enterprise Application Architecture) describes the way that
many systems evolve of their own accord. It is simple, intuitive, and effective, although it becomes less
so as systems grow. A transaction script handles a request inline, rather than delegating to specialized
objects. It is the quintessential quick fix. It is also a hard pattern to categorize, because it combines
elements from other layers in this chapter. I have chosen to present it as part of the business logic layer,
because the pattern’s motivation is to achieve the business aims of the system.
The Problem
Every request must be handled in some way. As you have seen, many systems provide a layer that
assesses and filters incoming data. Ideally, though, this layer should then call on classes that are
designed to fulfill the request. These classes could be broken down to represent forces and
responsibilities in a system, perhaps with a facade interface. This approach requires a certain amount of
careful design, however. For some projects (typically small in scope and urgent in nature) such a
development overhead can be unacceptable. In this case, you may need to build your business logic into
a set of procedural operations. Each operation will be crafted to handle a particular request.
The problem, then, is the need to provide a fast and effective mechanism for fulfilling a system’s
objectives without a potentially costly investment in complex design.
The great benefit of this pattern is the speed with which you can get results. Each script takes input
and manipulates the database to ensure an outcome. Beyond organizing related methods within the
same class and keeping the Transaction Script classes in their own tier (that is, as independent as
possible of the command and control and view layers), there is little up-front design required.
While business logic layer classes tend to be clearly separated from the presentation layer, they are
often more embedded in the data layer. This is because retrieving and storing data is key to the tasks that
such classes often perform. You will see mechanisms for decoupling logic objects from the database later
in the chapter. Transaction Script classes, though, usually know all about the database (though they can
use gateway classes to handle the details of their actual queries).
Implementation
Let’s return to my events listing example. In this case, the system supports three relational database
tables: venue, space, and event. A venue may have a number of spaces (a theater can have more than one
stage, for example; a dance club may have different rooms, and so on). Each space plays host to many
events. Here is the schema:
CREATE TABLE 'venue' (
'id' int(11) NOT NULL auto_increment,
'name' text,
PRIMARY KEY ('id')