OT: Re: Session facade
Maybe. Zhang, Larry \(L.\) [EMAIL PROTECTED] 07/07/2004 02:58 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To Struts Users Mailing List [EMAIL PROTECTED] cc 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]
RE: Session facade
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]
Re: Session facade
It will make sense. You'd let the j2ee container take care of managing dao manager instances and you'll get transaction support (if you need it). Plus, if you decide to move your persistence layer to another server it will be nicely packaged within the .ear that contains your ejb session facade. Best, James --- http://www.devbistro.com --- Zhang, Larry (L.) [EMAIL PROTECTED] wrote: 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] __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session facade
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]
RE: Session facade
+1 I would also add that the Facade should be an interface where the implementation can change without affecting the client code. I would also recommend looking at the Spring framework. It provides declarative transaction management without using EJB. I also provides a declarative way to plug-in interface implementations. http://www.springframework.org/ robert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 07, 2004 3:42 PM To: Struts Users Mailing List Subject: RE: Session facade 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]
Re: [OT] Session facade
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]
Re: [OT] Session facade
:) 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 [EMAIL PROTECTED] Sent by: news [EMAIL PROTECTED] 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 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]
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 :-) --- [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent by: news [EMAIL PROTECTED] 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 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] __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Session facade
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 Facade? I am reading http://java.sun.com/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 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 :-) --- [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent by: news [EMAIL PROTECTED] 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 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] __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - 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]
RE: [OT] Session facade
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:[EMAIL PROTECTED] 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 :-) --- [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent by: news [EMAIL PROTECTED] 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 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] __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: [OT] Session facade
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 [EMAIL PROTECTED] 07/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 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:[EMAIL PROTECTED] 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 :-) --- [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent by: news [EMAIL PROTECTED] 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 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
RE: [OT] Session facade
--- 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 Facade? I am reading http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html, and I think Session Facade itself should be a session EJB, right? It really doesn't have to be. The link you sent lists down three advantages of using a Facade object, and only the second one is really EJB-specific. I use Facade objects in my design and only decide later on how the facade will be implemented (ejb or pojo). Either way, you still reduce the coupling between the client and business objects, still expose a uniform interface, and still reduce/eliminate business logic in the client tier. Hubert __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session facade
Zhang, It depends on what you want. Using session facade gives your architecture forward compatibility towards EJB technologies and maybe new technologies that might come in ... the overhead of using this pattern isn´t that important and you will have a clearer separation of areas... Regards, Lucas - Original Message - From: Zhang, Larry (L.) [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, July 07, 2004 3:58 PM 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]
