struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gdesc...@cmhc-schl.gc.ca
Subject RE: [OT] Session facade
Date Wed, 07 Jul 2004 20:54:36 GMT
Well. In my case I used the Facade pattern without the Session.
I did have a discussion with a friend as to determine if it is closer to a 
 Delegate or a Facade.
Facade... eventhough it does not adhere to the J2EE Pattern 100%.





"Matthias Wessendorf" <mailings@matthias-wessendorf.de>
07/07/2004 04:45 PM
Please respond to "Struts Users Mailing List"




 
        To:     "'Struts Users Mailing List'" <user@struts.apache.org>
        cc: 

        Subject:        RE: [OT] Session facade
 Classification: 


yes it should be a SessionEJB

however, if you are new to EJB

look here, for generating EJBs
http://xdoclet.sf.net
and a Xdoclet-Petstore-Sample
http://xpetstore.sf.net




and Struts and EJBs
http://developers.sun.com/events/techdays/codecamps/

THE LINK:
Struts and Core J2EE Patterns Together Demo



and
https://strutsejb.dev.java.net/



i guess... now you have stuff...

:-)

cheers,

PS: J2EE-Patterns-Book is great!

Matthias


> However, before the discussion goes far from what I initially 
> wanted, let me ask you this: is your Facade the same as my 
> Session Facade? I am reading 
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/Sessi
> onFacade.html, and I think Session Facade itself should be a 
> session EJB, right?
> 
> 
> -----Original Message-----
> From: klute [mailto:soundres9@yahoo.com]
> Sent: Wednesday, July 07, 2004 4:34 PM
> To: Struts Users Mailing List
> Subject: Re: [OT] Session facade
> 
> 
> Agree with Bill here. Also... the Constants file is
> (or can be) quite 'C' as well. There is a temptation
> to put all of your constants in one place and before
> you know you end up putting all of your constants
> encountered within your app there. So totally
> unrelated stuff gets piled up into one place :-)
> 
> 
> 
> 
> --- gdeschen@cmhc-schl.gc.ca wrote:
> > :)
> > 
> > Perhaps I could have used Exceptions but well at
> > least I use a Constant
> > file.... a little better!
> > The more I think about the better it seems to
> > get.... damn I have some 
> > code rewriting to do...
> > 
> > Thanks Bill.
> > 
> > 
> > 
> > 
> > 
> > 
> > Bill Siggelkow <billsigg@bellsouth.net>
> > Sent by: news <news@sea.gmane.org>
> > 07/07/2004 04:10 PM
> > Please respond to "Struts Users Mailing List"
> > 
> > 
> > 
> > 
> > 
> >         To:     user@struts.apache.org
> >         cc:
> > 
> >         Subject:        Re: [OT] Session facade
> >  Classification:
> > 
> > 
> > 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
> > :)
> > 
> > gdeschen@cmhc-schl.gc.ca 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" <rcortes@boltstaff.com>
> > > 07/07/2004 03:28 PM
> > > Please respond to "Struts Users Mailing List"
> > > 
> > > 
> > > 
> > > 
> > > 
> > >         To:     "Struts Users Mailing List"
> > <user@struts.apache.org>
> > >         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:lzhang20@ford.com]
> > > 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:
> > user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail:
> > user-help@struts.apache.org
> > > 
> > > 
> > > 
> > > 
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail:
> > user-help@struts.apache.org
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > user-unsubscribe@struts.apache.org
> > For additional commands, e-mail:
> > user-help@struts.apache.org
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages! 
http://promotions.yahoo.com/new_mail 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message