RE: [OT] Session facade

2004-07-07 Thread Hubert Rabago
--- "Zhang, Larry (L.)" <[EMAIL PROTECTED]> wrote: > Thanks all. I especially like " Firstly, just in case that EJBs will be > introduced in subsequent phases." > > However, before the discussion goes far from what I initially wanted, let > me ask you this: is your Facade the same as my Session Fa

RE: [OT] Session facade

2004-07-07 Thread gdeschen
07/2004 04:45 PM Please respond to "Struts Users Mailing List" To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> cc: Subject:RE: [OT] Session facade Classification: yes it should be a SessionEJB however, if you

RE: [OT] Session facade

2004-07-07 Thread Matthias Wessendorf
M > 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 pu

RE: [OT] Session facade

2004-07-07 Thread Zhang, Larry \(L.\)
blueprints/corej2eepatterns/Patterns/SessionFacade.html, and I think Session Facade itself should be a session EJB, right? -Original Message- From: klute [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 07, 2004 4:34 PM To: Struts Users Mailing List Subject: Re: [OT] Session facade Agree with

Re: [OT] Session facade

2004-07-07 Thread klute
t; Thanks Bill. > > > > > > > Bill Siggelkow <[EMAIL PROTECTED]> > Sent by: news <[EMAIL PROTECTED]> > 07/07/2004 04:10 PM > Please respond to "Struts Users Mailing List" > > > > > > To: [EMAIL PROTECTED] >

Re: [OT] Session facade

2004-07-07 Thread gdeschen
; 07/07/2004 04:10 PM Please respond to "Struts Users Mailing List" To: [EMAIL PROTECTED] cc: Subject: Re: [OT] Session facade Classification: Glenn, I was with you until the part about the "return code" ... I think it would be bett

Re: [OT] Session facade

2004-07-07 Thread Bill Siggelkow
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" k