Opinions - facade Design Pattern

[John Bateman]

Hi
I using a Model 2 architecture wherein the controller class (servlet) dynamically instantiates ActionClasses. These action classes perform 1 single function on the system (RegisterUser, VerifyLogin, DeleteInvoice etc). Each action class MAY have to get information from the EJB (Business) layer via remote Interfaces.
My questions..
1- Do I put the logic to get the remote interfaces into each action class so that each class acts as/or has a mini facade to the EJB sub system?
2- Should I look into decoupling it even more and designing a big EJBFacade object that knows everything about the EJB layer and each ActionClass has an instance of this EJBFacade object?
I see each having pros and cons.
In the first example the ActionClass has it's and only it's interface. This way is small, but if something changes on the EJB layer side I 'may' have to edit all my action classes to incorporate the changes.
The EJBFacade way makes it easy to maintain the system if soemthing changes, but, it is a bulky heavyweight object that may instantiate/get interfaces that a specific action class never uses.
Part II:
As another monkey wrench to all this. What about an EJBFacade object using Eager Instantiation, where it only gets the remote interface when it's asked to get it?
Sorry for putting so many "if's" into this mail, but I am having a hard time grasping the right way to do this.

------------------
SOURCE CODE should be SURROUNDED by "code" tags.
Click here for an example

[David Roberts]

I don't work with EJB that much but here's my two cents...
Typically when I work with ASP/JSP I treat the Server Page (SP) as the glue to the View. So when I use something like a Facade Controller, it's a object within the domain itself. This gets tricky since one must post/querystring the page, which acts as your system function.
For Example (Simplified):
If I used BookStore as a facade contoller, it might have a:
retrieveSelectedBook(ID) method.
It may intern call a BookCatalog's retrieveSelectedBooks(ID).
I usually find that technology limitation, ie COM+ forces a more public approach. So each Object ends up handling their own System Events. Which intern makes the SP or Servlet look like the controller.
So I guess this is my advice:
I think your item 2 is more along the lines of what I do, I presume you're being general when you say a EJBFacade that knows everything about the EJB layer, I would create a Facade that knows about the particular part of the domain as opposed to all EJB interface.
Your Part II sounds like a virtual proxy. I'm not sure where you want to go with that, I do find that Virtual Proxys can result in Class Explosion (You're probably familiar) and it doesn't seem to payoff in the web unless you have a lot of almost instantiations where objects don't get created half or more then half the time...
I hope I understood you and made some sense. If not, well, disregard and some better advice is sure to come along...


------------------
David Roberts - SCJP2,MCP