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).
|