• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Difference between Facade, Front Controller and command pattern

 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear All,

I do not really possess deep understanding of many mystical design patterns and terms used in them. I have googled also without too much of layman help. I was wondering if someone could spare time and be kind enough to let me know the difference between front controller, facade (Session Facade : is in terms of EJBs I guess, am I correct ?) and command pattern.
From my current undestanding the essential difference between em is

facade
Gives a single entry point for objects and I suppose base on a lot of if else's fetches the right implementation. All in all : simplifies the access process.
front controller : Is again a single entry point for accessing other complex lines of code. All in all: simplifies the access process.
command pattern : Based on the case the specific objects are called. All in all: simplifies the access process.

Kindly help the confused mind


rgds
[ October 17, 2007: Message edited by: Mike Anna ]
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
     
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    A couple minor nits ...

    A Facade might contain "business logic." While it's not usually the driver for having a Facade, even Shalloway's article talks about using one to add functionality. Depending on today's definition of "business," simply orchestrating a sequence of low level calls might qualify.

    A Facade (or class visibility) might "prevent applications from using subsystem classes" if the implementer wants the freedom to add, change or remove subsystem classes over time. I worked on one system where one Facade per module/team made the only public APIs and it worked out to great effect.

    Session Facade was an unfortunate term and definition. I have used Session Beans that were Facades, but not Session Facades. Enough to make your head hurt for sure.
     
    Mike Anna
    Ranch Hand
    Posts: 117
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Great. Thanks a ton for your replies. I will give some time for this to sink in, though :roll:

    Rgds
    [ October 18, 2007: Message edited by: Mike Anna ]
     
    Ranch Hand
    Posts: 30
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    A facade is exactly what it means in the english language...something that acts as a front to other things. It is not a single point of access in the frontcontroller sense. For example a facade may expose 1 business API that may aggregate 3 separate business APIs...so instead of calling 3 separate methods you call only 1 making the API simpler to use.

    A frontcontroller manages delegation, it recieves a request and then decides which module should handle that request.
     
    pie. tiny ad:
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    reply
      Bookmark Topic Watch Topic
    • New Topic