Discussions

General J2EE: Can the Facade be optional? (Controller talks to DAO)

  1. I think the Facade is a great pattern, but is it always necessary? Is there a problem with the controller (An Action object in Struts) making a request to the Data Access Object (DAO) directly in very simple cases?

    Here's an example using the Facade & DAO patterns:

    Action:

    Set plants = facade.getAllPlants();

    Facade:

    public Set getAllPlants() {
      return PlantDAO.getInstance().getAllPlants();
    }

    PlantDAO:

    public Set getAllPlants() {
      // get all Plant objects from database
    }

    In this example, the facade doesn't add any value. It's just another layer of indirection. If we remove it, we have:

    Action:

    Set plants = PlantDAO.getInstance().getAllPlants();

    PlantDAO:

    public Set getAllPlants() {
      // get all Plant objects from database
    }

    In the second example, we have eliminated one method and one layer of indirection! The J2EE design patterns advocate the use of the facade, and I totally agree when the facade adds some value. For example, when validating a user's login, there would be some logic involved in checking the supplied password with the password stored in the database. This should only be in one place, therefore the facade is perfect. But when the facade is so simple it just delegates a call to another object, is it worth it? What are the disadvantages to this more direct approach?

    Michael

  2. The point of a facade in this particular circumstance is to reduce work in the future.

    At present you are using DAOs, but say the decision is reached that they will have to be replaced with EJBs (say the transactional control is too complicated otherwise or maybe the pooling/load balancing behaviour becomes critical), I would much rather recode a trivial method behind a facade than replace all references to the DAO throughout an application. The use of a facade here is to decouple your application code from the exact implementation of your persistence (and maybe business logic).

    You might argue that you could recode the DAO to use EJBs to do the persistence - however what you were calling the DAO has now become a facade and you have in fact ended up with a 'partial double facade' (two different facade types exposed to your application code, one sitting partially on top of the other) and you lose consistency - fun eh?

    Another argument for being consistent in your use of facades is that when you have to hand the application over to other developers for support, it is much easier to explain a facade layer consistently talking to a DAO layer than to explain all the times that you decided to shortcut it...

    If you can say, hand on your heart, that you will never, ever replace the DAOs with EJBs (or JDO or whatever), you will be the only person ever to support it and the performance enhancements gained by this are really worth breaking consistency then...

    I hope this helps.

    Bob B.
  3. I understand the need for consistency, that was one of my arguments for keeping the facade. And I also appreciate the flexibility to change what's behind it. But at the same time, I absolutely hate putting something in because "I might need it later". The XP motto "YAGNI!" (You Ain't Gonna Need It!" keeps coming back to me. But however, even if we do change the DAO to EJB or whatever, I still don't think it'd be that hard to make the change. I think it'd be easier than coding up extra methods in the facade, testing them, and carrying that code around for 6 months without really needing it.

  4. I know what you mean. To be honest I was thinking that this may not be a combination of patterns that I would choose to use in your situation.

    It looks like you are using the facade pattern to begin to isolate your application/display logic from your service logic. Your login example being a case in point.

    I would suggest that instead of using Facade/DAO instead look at creating an architecture of reusable service objects with your struts application talking to these service objects or the DAOs as necessary. You are already partway down the path to this with what you have described, you really only need to change your terminology :-)

    Bob B.
  5. I guess it all depends on what it is exactly that you are trying model. Facades are great when you have to centralize workflow, manage transactions across a number of different objects and resources, prevent too many RMI invocations, and to prevent business objects creeping into the presentation tier. If you have no workflow, your not worried about transactions, your using local interfaces instead of remote ones and you have no business logic, then you don't need a facade =).

    I think this tends to really only be an issue for read-only kinds of operations where you are simply doing a database query and returning the results for display to the end user.

    Another consideration can be security. If you call the DAO directly, you bypass any container security you may have in place.
  6. A lot of those issues do not exist when running outside of an EJB container. Specifically I'm talking about a project that is mostly readonly displaying data from a database. I think you're right when the project is to do something more complicated the facade has a lot to offer.

    I think it's easy to blindly accept design patterns without thinking them through and evaluating their usefulness.

    Michael