Difference between Command and Session Facade

[dennis zined]

hi all. Can somebody please explain the difference between the Command Pattern and the Session Facade pattern. I'm currently reading EJB Design Patterns by Floyd Marinescu and a paragraph on page 19 states:

"Use the Command pattern to wrap business logic in lightweight command beans that decouple the client from EJB, execute in one network call, and act as a facade for the EJB layer."

Isnt this the same as Session Facade? The next paragraph states:

Applied to EJB, the Command pattern provides a lightweight solution for achieving the same benefits as the Session Facade and Business Delegate patterns.

So does this mean that if a business delegate component acting as a client to the Session Facade, it is in effect, doing a Command pattern?
Any help is greatly appeciated. thanks.

[Stan James]

A Command object encapsulates behavior. You might have a bunch of commands that all implement an interface with a single method execute(). For exapmle I have a little web server with something like

public void handlePostForm( Request request )
{
   String formName = aRequest.getParameter("formname");
   String action = aRequest.getParameter("buttonpushed");
   Command cmd = cmdMap.get( formName + action );
   cmd.execute( request );
}

Every form has two hidden fields - formname and the button pushed. I use a combination of the two to get the right command object, and execute it. So I have one command class for Editor + Save, another for Administrator + Shutdown. Each encapsulates all the behavior for one operation. I can add more commands just by adding configuration that maps the form+action to a command class.
Commands are also neat because you can pass them around. A client could call you with a Command parameter. All you know is you should call execute(). You don't have to have any idea what it's going to do. An interesting way to distribute behavior.
Session Facade usually tries to hide a complex set of objects and operations behind a single, simple interface. For example the facade might have FindCustomer and AddCustomer methods. The client comes to one object for both of these functions. But in fact the functions are implemented in separate objects or a bunch of objects. The client never needs to know about this complexity.
Business Delegate can do some of the Facade thing - providing simple APIs to complex implementations. But even if its methods are a one-to-one match with an EJB, it hides the complexity of the protocol. To call a normal EJB you get context, use JNDI, use a home finder, get a stub, handle remote exceptions, many lines of pretty tricky stuff. The provider of the EJB could give you a Business Delegate that hides all of that. You just call methods and get results. That can be pretty nice even if the EJB provider and the client are both you. The client code that uses the delegate is vastly simplified, perhaps in many places in the client code.
Now I guess if the client instantiated a Command, passed it through a Business Delegate (or not) and the Command then did a bunch of complex things on the server, the command would be a bit of a Facade. And maybe my web server example with a single handlePostForm is a bit of a facade, too. I think I'd prefer to think of Command and Facade as different things, but they could have similar benefits in the right design.
[ February 18, 2004: Message edited by: Stan James ]

[dennis zined]

Hi Stan. This is awesome. Thank you for your reply.