Command Pattern
Consider our use case of having a Bank and a user who wants to perform
banking opeations like withdraw, deposit, etc. The Session Pattern,
allowed us to seperate and remove business logic from the client layer
and place it is a "session facade layer" of classes (session
beans). However, there is still some coupling between clients and the
business logic use-case methods they request to be executed int the
Session Facade layer classes (session beans).
Problems:
- Still coupling between client and session layers.
A Solution.....the Command Pattern
Have plain classes (not beans) with "get", "set"
and "execute" methods that act as "Command classes"
and are the interface between a client and any underlying business logic
(in the session layer).
Each Command class is used to encapsulate individual units of work
in an application.
Example
"TransferFunds" command class
1) Client creates command object (or gets one)
2) Client sets() attributes of command (data needed in use case).
3) Client calls command object's execute().
4) Now this code is actually run on the server (possibly same server as
session and entity beans). This turns into invoking a session layer method
(session bean) and in turn accessing data layer (entity beans) or other
resources. SEE NOTE BELOW
4) Client calls gets() on command object to retrieve results of the execution
of the use case.
NOTE: Setting up the infrastructure
How is the "translation" of the execute command to the execution
of session beans and underlying entity beans to execute the requested
use-case (business logic) performed. There are some frameworks developed
that implement the Command Facade. IBM's Command framework (first part
of Websphere) is one such product. Here are some of the elements:
- Command Beans. Java bean (not EJB) class with gets, sets and
execute method. Developer creates there own subclass.
- Client-side Routing Logic. Framework of classes that is provided
an takes a Comand object and sends it to the remote EJB server. This
is not visible to the client and is triggered by calling a command's
execute method. It is a set of generic classes provided that can be
reused accross projects. (e.g. CommandExecutor, EJBCommandTarget classes
could take a command and send it to a EJB server for consumption).
- Remote Command Server. A service that simply accepts commands
and executes them. A class, CommanServer, that is a stateless session
bean that accepts a command as a parameter and executes it locally.
This is a provided, generic class and is completely reusable across
projects.
Synopsis: Command Facade
Name: Command Facade
Context
A client needs to execute business logic in order to complete
a use case.
Problem (forces)
How can a developer implement a use case's business logic in
a LIGHTWEIGHT manner, decoupling client from business logic, data
layers and executing the use case in one transaction and one network
call?
Solution
Use the Command pattern to wrap business logic in a lightweight
command classes (beans) that decouple the client from underlying
logic classses (session and entity beans), execute in one network
call, and act as a facade for the logic layer (session and entity
EJBs)
Related Patterns
Session Facade.
|
PROBLEM:
Need supporting classes....otherwise, a lot to
develop (but, can reuse).
|