Commands are convenient because the implementation behind the com-
mand layer does not matter. The interface is the same whether the command
is accessing a full object-oriented model, a legacy COBOL application, messag-
ing-oriented middleware, a transaction, or a database, as in our example. A
command is a thin layer around the model, sometimes called the command
bean . The command bean's interface consists of a series of sets representing
input parameters, a validation to check the input parameters, an execute to
access some aspect of the business model, and a series of get s to access the
results of the execution. The command architecture does not make any
assumptions about the structure of the model, giving the command bean
It can be tooled or generated by a wizard. Many tools already generate
command beans, and a simple generator for them is easy to create.
A generic command can be subclassed to encapsulate remote procedure
calls ( RPC ). The API s for commands and RPC s are remarkably similar.
It is a convenient architecture for encapsulating undo / redo architec-
tures. With the simple addition of an undo method, commands can be
saved and undone or redone.
It can package multiple requests to save round trips.
The interface is always the same, making our code much easier to main-
tain and read.
Think of the command bean as a simple interface to an RPC . The interface sets
a series of input parameters for the execution of the call. Then, the command
validates the request, executes it, and returns the results. The results are
achieved through a series of get s.
Separating the model logic
The following program shows a command object that returns the database
records from a table called posts. The basic form of a command is a set of
set methods for input parameters, an optional initialize method, and an
execute method, as well as a series of get methods for output parameters.
You may include additional private methods to handle such tasks as database
connections, but the basic form for all commands is the same.