First of all: Session Facade is not a Facade. Session Facade is the name for a
J2EE pattern where you apply a remote interface to a bunch of
Transaction Scripts (which are usually considered part of the Session Facade).
A Facade in the general sense does not contain any business logic - the Session Facade often does.
A Facade is placed in front of a bunch
POJOs; the business logic is contained in the POJOs and they are
not part of the Facade.
When you push your business logic into an
Application Service (instead of keeping it as a bunch of transaction scripts), the Session Facade starts to
resemble a
Remote Facade.
Article: Understanding The Facade Pattern There is also sometimes confusion between a Session Facade and a Business Delegate. Have a look at
this.
A client of a Facade decides with of the many methods to call. The front controller isn't in direct contact with the client. The front controller receives a request that originated from the client. The front controller inspects that request and the
Front controller decides what code to call (as opposed to the client). Then it returns the resulting response.
PoEAA: Front Controller Core J2EE Patterns 2e: Front Controller Core J2EE Patterns: Front Controller Blueprints: Front Controller Compare the Facade Consequences to the Command Consequences (GoF):
Facade
It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use. It promotes weak coupling between the subsystem and its clients. Often the components in a subsystem are strongly coupled. Weak coupling lets you vary the components of the subsystem without affecting its clients. Facades help layer a system and the dependencies between objects. They can eliminate complex or circular dependencies. This can be an important consequence when the client and the subsystem are implemented independently.Reducing compilation dependencies is vital in large software systems. You want to save time by minimizing recompilation when subsystem classes change. Reducing compilation dependencies with facades can limit the recompilation needed for a small change in an important subsystem. A facade can also simplify porting systems to other platforms, because it's less likely that building one subsystem requires building all others. It doesn't prevent applications from using subsystem classes if they need to. Thus you can choose between ease of use and generality. Command
Command decouples the object that invokes the operation from the one that knows how to perform it. Commands are first-class objects. They can be manipulated and extended like any other object. (With facades you simply use the methods of the facade). You can assemble commands into a composite command. It's easy to add new Commands, because you don't have to change existing classes. (To add a method to a facade you have to change existing classes) Both patterns enhance decoupling/weak coupling - otherwise they aren't related. The Facade pattern is a structural pattern, while the Command pattern is a behavioral pattern.
Command Pattern Facade Pattern
