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]
