Glenn, I was with you until the part about the "return code" ... I think it would be better to translate the DAOException to some BusinessServiceException or something similar instead of a "return code".
Generally, I try and avoid the "method returns a -1 to indicate that the operation failed" kind of thing -- it is so 'C' like :)


[EMAIL PROTECTED] wrote:

my 2 cents...

I am using the Facade in my current project.

Firstly, just in case that EJBs will be introduced in subsequent phases.

Secondly, the DAO throws exceptions of DAOException & a FatalException.
Say that a Stored Procedure returns an application error (invalid parameter in a SP); this is treated as a DAOException.
Say that the DB is not there this is treated as a FatalException.


The Facade catches and interprets the DAOException with a Return Code.
Say that the DB is used to authenticate a User Id and Password.
The Facade is where the DAOException to translated into a simple Return Code that the Action will check for.


This a way the Action classes are nice a clean!
- Glenn





"Ricardo Cortes" <[EMAIL PROTECTED]>
07/07/2004 03:28 PM
Please respond to "Struts Users Mailing List"




To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:


Subject: RE: Session facade
Classification:



I would assert you don't need the Session Facade as one of the advantages of the Session Facade is it's ability to abstract the low level operations of the Session EJBs from upper layers of your architecture. You could probably have your actions talking to a Business Delegate layer or your DAO layer directly. Of course, this is just one viewpoint.


-----Original Message-----
From: Zhang, Larry (L.) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 07, 2004 2:59 PM
To: Struts Users Mailing List
Subject: Session facade



It seems session facade design pattern is becoming ubiquitous. My question is that if we are not going to use EJB(but we do have DAO-data access object), does it still make sense to use session facade?

Thanks.



---------------------------------------------------------------------
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]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to