Adam, IMHO the Business Delegate pattern abstracts the client from knowing
your business implementation, whether it be EBJ, JDO, POJO, roll your own. The
client interfaces with the Business Delegate and not its implementation.
For example, if you have an Action (client) interface with the Business Delegate
instead of directly with a SessionFacade, then you can change the underlying
implementation
of the Business Delegate without changing anything in the client.
If your really paranoid (or prepared), you can use the Abstract Factory pattern which
you could then
initialize/subclass to create the appropriate Business Delegate implementations (EJB,
JDO, main frame).
Also by using a Business Delegate the client isn't exposed to implementation details
such as (if your using EJB) looking up the appropropriate EJB or handling
implementation
specific exceptions. The Business Delegate becomes a high level abstraction of the
business rules raising application level exceptions when error occur to which the
client
can respond appropriately.
So, you wouldn't necessarily have to modify the Delegate-Facade interface. The
interface
itself remains unchanged. You have to use a different implementation. That is where
the
factory comes in. I imagine you could do something like the following:
Properties props = // get initialization properties
// to initialize factory to return EJB BD implementations
BusinessDelegateFactory bdf = BusinessDelegateFactory.init(props);
In your client, suppose AccountBD is your BusinessDelegate interface:
BusinessDelegateFactory bdf = BusinessDelegateFactory.getInstance();
AccountBD accountBD = (AccountBD)bdf.createBusinessDelegate(AccountBD.BD_NAME);
So you just end up "plugging" in new implementations as needed.
Anyhow, that's my interpretation of the some of the forces behind the pattern
and an idea on implementing it.
Here's more information:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
http://www.developer.com/java/other/article.php/626001
robert
> -----Original Message-----
> From: Adam Hardy [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 16, 2004 6:26 PM
> To: Struts Users Mailing List
> Subject: action - delegate - facade
>
>
> I've just been perusing the archive to check out what people have been
> saying about struts to EJB interfacing.
>
> One thing that occurs to me is that the only reason mentioned for having
> a business delegate layer between the Actions and the Session Facade is
> to allow for loose coupling of the struts-dependent code with the EJB
> dependent code.
>
> How necessary is that? If you choose to drop EJB and go with, say
> Hibernate, you would have to modify the interface, whether it is the
> Action - Facade interface or the Delegate - Facade interface.
>
> Or have I missed an important other reason for the existence of the
> Delegate layer?
>
> Adam
> --
> struts 1.1 + tomcat 5.0.16 + java 1.4.2
> Linux 2.4.20 Debian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
