RE: DAO or ... ? [Scanned for known viruses]
Would it better/worse to move the getValueObject() method out of CustomerForm.java, so you could use DynaActionForms and not have to write CustomerForm.java? Maybe it could go in a reusable class that knows how to get various ValueObjects from various DynaActionForms. Thanks, Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 11:13 AM To: Struts Users Mailing List Subject: RE: DAO or ... ? [Scanned for known viruses] James - I've attached a few files from my upcoming book Struts Kick Start that provide a basic design pattern that sounds like it may be similar to what your describing. What I do is: - Create a Value Object that encapsulates data communicated with the Model component. - Create a facade class that accepts and returns value objects through 'business methods'. By defining the facade to work at a 'business method' level, it helps keep any code related to a particular persistence layer or back-end system out of the Action class. This also addresses the issues you described of 'designing to test' - the clean seperation between the Action class and the Model components that the Facade provides simplifies testing. - Create the form bean to provide set/get methods that also accept and return value objects - this greatly simplifies the Action class and isolates it from changes. The Action class (a bit simplified - I've taken out detailed comments and exception handling) goes something like: // cast the form bean CustomerForm cf = (CustomerForm) form; // Create a facade to interface to the back-end system CustomerWSFacade facade = new CustomerWSFacade(); // Extract the value object from the form bean CustomerValueObject cvo = cf.getValueObject(); // Pass the value object to the facade. It returns an update value object cvo = facade.addressChange( cvo ); // Use the returned value object to update the values in the form bean. cf.setValueObject(cvo); These particular classes come from the chapter on providing integration with Axis for Web Services. Another chapter uses the identical set of classes to communicate with JBoss using a Session Bean - all I did was write a different facade class. The point of this was to demonstrate a design that made it very simple to perform maintenance or changes on the back-end or persistence layer. Regarding testing - I'd recommend you take a look at the StrutsTestCase project at sourceforge - it provides some great templates for both JUnit and Cactus tests that are designed for Struts. Makes JUnit/Cactus testing pretty straightforward. A copy of this and detailed directions also come with the book. http://strutstestcase.sourceforge.net/ Best of luck - Kevin Author, Struts Kick Start (See attached file: customer.zip) Couball, James [EMAIL PROTECTED] on 10/14/2002 01:19:16 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To:'Struts Users Mailing List' [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:RE: DAO or ... ? I recommend taking a look at the Session Façade pattern in the Java Blue Prints. No matter if you use EJBs or not, this pattern encapsulates the ideas that Simon was mentioning. Does anyone know the name of the more general pattern that doesn't involve Session Beans specifically? One of my general concerns is design to test. I like to be able to test the (business/persistence) layer that the actions will call independently of struts, actions, etc. Encapsulating that layer in an API (or wrapping with a session bean) makes this possible. Sincerely, James. -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 8:16 AM To: Struts Users Mailing List Subject: RE: DAO or ... ? But you still call the API from the action right - is this not invoking the functionality that persists your data? Seems a bit like semantic juggling to me... (after all the persistance layer is just an abstraction API on top of writing to db/disk/punchcard itself...) ;-) I would however agree that there ought to be some sort of abstracting layer between the view and the implementation specific details of the p-tier... -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 23:04 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: DAO or ... ? You invoke your persistence code in the same place that you would invoke any other code ... not in the Action! Write all your core application code (business rules, persistence, communications etc) in a way that has no connection to the view portion
RE: DAO or ... ? [Scanned for known viruses]
Not sure - I didn't really look at that in the design. I liked how this approach allowed me to modify the form bean and/or the Value Object without having to make any changes to the Action class. I was trying to create an instructive example, not so much create the ultimate design. We had covered DynaActionForms elsewhere and I didn't want to do too much at once. The real goal was definition of the facade and model components. The biggest value is using this pattern to define a clean break between the Action class and the Model components - i.e., the facade in front of the web service. By doing this, you create a design where changing the back-end system - a little or a lot - has little to no effect on the Action class. I do like your idea of a reusable class. Expecially if I had a bunch of forms to process. Dan Cancro [EMAIL PROTECTED] on 10/15/2002 02:47:59 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To:'Struts Users Mailing List' [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:RE: DAO or ... ? [Scanned for known viruses] Would it better/worse to move the getValueObject() method out of CustomerForm.java, so you could use DynaActionForms and not have to write CustomerForm.java? Maybe it could go in a reusable class that knows how to get various ValueObjects from various DynaActionForms. Thanks, Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 11:13 AM To: Struts Users Mailing List Subject: RE: DAO or ... ? [Scanned for known viruses] James - I've attached a few files from my upcoming book Struts Kick Start that provide a basic design pattern that sounds like it may be similar to what your describing. What I do is: - Create a Value Object that encapsulates data communicated with the Model component. - Create a facade class that accepts and returns value objects through 'business methods'. By defining the facade to work at a 'business method' level, it helps keep any code related to a particular persistence layer or back-end system out of the Action class. This also addresses the issues you described of 'designing to test' - the clean seperation between the Action class and the Model components that the Facade provides simplifies testing. - Create the form bean to provide set/get methods that also accept and return value objects - this greatly simplifies the Action class and isolates it from changes. The Action class (a bit simplified - I've taken out detailed comments and exception handling) goes something like: // cast the form bean CustomerForm cf = (CustomerForm) form; // Create a facade to interface to the back-end system CustomerWSFacade facade = new CustomerWSFacade(); // Extract the value object from the form bean CustomerValueObject cvo = cf.getValueObject(); // Pass the value object to the facade. It returns an update value object cvo = facade.addressChange( cvo ); // Use the returned value object to update the values in the form bean. cf.setValueObject(cvo); These particular classes come from the chapter on providing integration with Axis for Web Services. Another chapter uses the identical set of classes to communicate with JBoss using a Session Bean - all I did was write a different facade class. The point of this was to demonstrate a design that made it very simple to perform maintenance or changes on the back-end or persistence layer. Regarding testing - I'd recommend you take a look at the StrutsTestCase project at sourceforge - it provides some great templates for both JUnit and Cactus tests that are designed for Struts. Makes JUnit/Cactus testing pretty straightforward. A copy of this and detailed directions also come with the book. http://strutstestcase.sourceforge.net/ Best of luck - Kevin Author, Struts Kick Start (See attached file: customer.zip) Couball, James [EMAIL PROTECTED] on 10/14/2002 01:19:16 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To:'Struts Users Mailing List' [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:RE: DAO or ... ? I recommend taking a look at the Session Façade pattern in the Java Blue Prints. No matter if you use EJBs or not, this pattern encapsulates the ideas that Simon was mentioning. Does anyone know the name of the more general pattern that doesn't involve Session Beans specifically? One of my general concerns is design to test. I like to be able to test the (business/persistence) layer that the actions will call independently of struts, actions, etc. Encapsulating that layer in an API (or wrapping with a session bean) makes this possible. Sincerely, James. -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED
Re: DAO or ... ? [Scanned for known viruses]
Q: How would you re-use this in Model 1? .V [EMAIL PROTECTED] wrote: James - I've attached a few files from my upcoming book Struts Kick Start that provide a basic design pattern that sounds like it may be similar to what your describing. What I do is: - Create a Value Object that encapsulates data communicated with the Model component. - Create a facade class that accepts and returns value objects through 'business methods'. By defining the facade to work at a 'business method' level, it helps keep any code related to a particular persistence layer or back-end system out of the Action class. This also addresses the issues you described of 'designing to test' - the clean seperation between the Action class and the Model components that the Facade provides simplifies testing. - Create the form bean to provide set/get methods that also accept and return value objects - this greatly simplifies the Action class and isolates it from changes. The Action class (a bit simplified - I've taken out detailed comments and exception handling) goes something like: // cast the form bean CustomerForm cf = (CustomerForm) form; // Create a facade to interface to the back-end system CustomerWSFacade facade = new CustomerWSFacade(); // Extract the value object from the form bean CustomerValueObject cvo = cf.getValueObject(); // Pass the value object to the facade. It returns an update value object cvo = facade.addressChange( cvo ); // Use the returned value object to update the values in the form bean. cf.setValueObject(cvo); These particular classes come from the chapter on providing integration with Axis for Web Services. Another chapter uses the identical set of classes to communicate with JBoss using a Session Bean - all I did was write a different facade class. The point of this was to demonstrate a design that made it very simple to perform maintenance or changes on the back-end or persistence layer. Regarding testing - I'd recommend you take a look at the StrutsTestCase project at sourceforge - it provides some great templates for both JUnit and Cactus tests that are designed for Struts. Makes JUnit/Cactus testing pretty straightforward. A copy of this and detailed directions also come with the book. http://strutstestcase.sourceforge.net/ Best of luck - Kevin Author, Struts Kick Start (See attached file: customer.zip) Couball, James [EMAIL PROTECTED] on 10/14/2002 01:19:16 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To:'Struts Users Mailing List' [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:RE: DAO or ... ? I recommend taking a look at the Session Façade pattern in the Java Blue Prints. No matter if you use EJBs or not, this pattern encapsulates the ideas that Simon was mentioning. Does anyone know the name of the more general pattern that doesn't involve Session Beans specifically? One of my general concerns is design to test. I like to be able to test the (business/persistence) layer that the actions will call independently of struts, actions, etc. Encapsulating that layer in an API (or wrapping with a session bean) makes this possible. Sincerely, James. -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 8:16 AM To: Struts Users Mailing List Subject: RE: DAO or ... ? But you still call the API from the action right - is this not invoking the functionality that persists your data? Seems a bit like semantic juggling to me... (after all the persistance layer is just an abstraction API on top of writing to db/disk/punchcard itself...) ;-) I would however agree that there ought to be some sort of abstracting layer between the view and the implementation specific details of the p-tier... -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 23:04 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: DAO or ... ? You invoke your persistence code in the same place that you would invoke any other code ... not in the Action! Write all your core application code (business rules, persistence, communications etc) in a way that has no connection to the view portion of your system and then create a API to it. This way you can have any client you like call into your core code and your core code doesn't need to worry about what calls it, only about acting upon requests. Then use the actions to call into the API and pass the API return values to the JSPs. Works great. /--\/---\ /\ |Client|-- |API|--|Core| |Code || | |Code| \--/\---/ \/ The API is now your fire break. Nothing on the Core Code side has to worry about displaying anything and nothing in
Re: DAO or ... ? [Scanned for known viruses]
Model 1? I assume you're referring to the practice of posting directly to a jsp page instead of through an Action servlet - the model 1 that was proposed in the original JSP 0.92 spec. (For those who haven't reviewed it, the JSP 0.92 specificiation was the first place I believe the terms 'Model 1' and 'Model 2' originated. At least that's the earliest I remember seeing it. Here's a link to an old copy of it: http://www.kirkdorffer.com/jspspecs/jsp092.html . It still provides one of the best explanations of the difference between Model 1 and Model 2 that I've come across.). Not sure. I'd suppose you'd create a bean (and access it using a classic jsp:usebean) that is essentially your 'Model' component. This would have to be the equivalent of the 'Form Bean'. You set all the properties on this 'form bean' (using a scriptlet potentially) and then execute some method on it that would invoke this whole back-end process. (there are other potential ways of doing it - this is just one.) The facade and the other statements would be invoked from your bean. Once this processing was done, you could either extract properties from the same bean to populate the 'View', or you could extract another bean (that was a Value Object) from the first bean and drive the display results from it. This actually demonstrates the strength of Struts - the model 1 solution is more complex lends itself to embedding scriptlets faster. Also, a big problem is what do you do when things go wrong communicating to the back end? In Model 1, you have to trap the error and do a jsp:forward or just put conditional processing in the JSP directly - using Struts you simply catch the exception and forward to a different ActionForward. Kevin V. Cekvenich [EMAIL PROTECTED]@main.gmane.org on 10/15/2002 08:43:46 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] Sent by:news [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:Re: DAO or ... ? [Scanned for known viruses] Q: How would you re-use this in Model 1? .V [EMAIL PROTECTED] wrote: James - I've attached a few files from my upcoming book Struts Kick Start that provide a basic design pattern that sounds like it may be similar to what your describing. What I do is: - Create a Value Object that encapsulates data communicated with the Model component. - Create a facade class that accepts and returns value objects through 'business methods'. By defining the facade to work at a 'business method' level, it helps keep any code related to a particular persistence layer or back-end system out of the Action class. This also addresses the issues you described of 'designing to test' - the clean seperation between the Action class and the Model components that the Facade provides simplifies testing. - Create the form bean to provide set/get methods that also accept and return value objects - this greatly simplifies the Action class and isolates it from changes. The Action class (a bit simplified - I've taken out detailed comments and exception handling) goes something like: // cast the form bean CustomerForm cf = (CustomerForm) form; // Create a facade to interface to the back-end system CustomerWSFacade facade = new CustomerWSFacade(); // Extract the value object from the form bean CustomerValueObject cvo = cf.getValueObject(); // Pass the value object to the facade. It returns an update value object cvo = facade.addressChange( cvo ); // Use the returned value object to update the values in the form bean. cf.setValueObject(cvo); These particular classes come from the chapter on providing integration with Axis for Web Services. Another chapter uses the identical set of classes to communicate with JBoss using a Session Bean - all I did was write a different facade class. The point of this was to demonstrate a design that made it very simple to perform maintenance or changes on the back-end or persistence layer. Regarding testing - I'd recommend you take a look at the StrutsTestCase project at sourceforge - it provides some great templates for both JUnit and Cactus tests that are designed for Struts. Makes JUnit/Cactus testing pretty straightforward. A copy of this and detailed directions also come with the book. http://strutstestcase.sourceforge.net/ Best of luck - Kevin Author, Struts Kick Start (See attached file: customer.zip) Couball, James [EMAIL PROTECTED] on 10/14/2002 01:19:16 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To:'Struts Users Mailing List' [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:RE: DAO or ... ? I recommend taking a look at the Session Façade pattern in the Java Blue Prints. No matter if you use EJBs or not, this pattern encapsulates the ideas
Re: DAO or ... ? [Scanned for known viruses]
OK, so your formBean would be called via use bean. And the form bean would have some method to do the rest of persistence or populating? OK. That is kid of what I was driving to. One deals with beans. Beans have technology designs (patters) ... but they are there to do bus. requirements (your problem/bus domain patterns/solutions) .V (of course Model 2 is better) [EMAIL PROTECTED] wrote: Model 1? I assume you're referring to the practice of posting directly to a jsp page instead of through an Action servlet - the model 1 that was proposed in the original JSP 0.92 spec. (For those who haven't reviewed it, the JSP 0.92 specificiation was the first place I believe the terms 'Model 1' and 'Model 2' originated. At least that's the earliest I remember seeing it. Here's a link to an old copy of it: http://www.kirkdorffer.com/jspspecs/jsp092.html . It still provides one of the best explanations of the difference between Model 1 and Model 2 that I've come across.). Not sure. I'd suppose you'd create a bean (and access it using a classic jsp:usebean) that is essentially your 'Model' component. This would have to be the equivalent of the 'Form Bean'. You set all the properties on this 'form bean' (using a scriptlet potentially) and then execute some method on it that would invoke this whole back-end process. (there are other potential ways of doing it - this is just one.) The facade and the other statements would be invoked from your bean. Once this processing was done, you could either extract properties from the same bean to populate the 'View', or you could extract another bean (that was a Value Object) from the first bean and drive the display results from it. This actually demonstrates the strength of Struts - the model 1 solution is more complex lends itself to embedding scriptlets faster. Also, a big problem is what do you do when things go wrong communicating to the back end? In Model 1, you have to trap the error and do a jsp:forward or just put conditional processing in the JSP directly - using Struts you simply catch the exception and forward to a different ActionForward. Kevin V. Cekvenich [EMAIL PROTECTED]@main.gmane.org on 10/15/2002 08:43:46 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] Sent by:news [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:Re: DAO or ... ? [Scanned for known viruses] Q: How would you re-use this in Model 1? .V [EMAIL PROTECTED] wrote: James - I've attached a few files from my upcoming book Struts Kick Start that provide a basic design pattern that sounds like it may be similar to what your describing. What I do is: - Create a Value Object that encapsulates data communicated with the Model component. - Create a facade class that accepts and returns value objects through 'business methods'. By defining the facade to work at a 'business method' level, it helps keep any code related to a particular persistence layer or back-end system out of the Action class. This also addresses the issues you described of 'designing to test' - the clean seperation between the Action class and the Model components that the Facade provides simplifies testing. - Create the form bean to provide set/get methods that also accept and return value objects - this greatly simplifies the Action class and isolates it from changes. The Action class (a bit simplified - I've taken out detailed comments and exception handling) goes something like: // cast the form bean CustomerForm cf = (CustomerForm) form; // Create a facade to interface to the back-end system CustomerWSFacade facade = new CustomerWSFacade(); // Extract the value object from the form bean CustomerValueObject cvo = cf.getValueObject(); // Pass the value object to the facade. It returns an update value object cvo = facade.addressChange( cvo ); // Use the returned value object to update the values in the form bean. cf.setValueObject(cvo); These particular classes come from the chapter on providing integration with Axis for Web Services. Another chapter uses the identical set of classes to communicate with JBoss using a Session Bean - all I did was write a different facade class. The point of this was to demonstrate a design that made it very simple to perform maintenance or changes on the back-end or persistence layer. Regarding testing - I'd recommend you take a look at the StrutsTestCase project at sourceforge - it provides some great templates for both JUnit and Cactus tests that are designed for Struts. Makes JUnit/Cactus testing pretty straightforward. A copy of this and detailed directions also come with the book. http://strutstestcase.sourceforge.net/ Best of luck - Kevin Author, Struts Kick Start (See attached file: customer.zip
Re: DAO or ... ? [Scanned for known viruses]
Exactly. V. Cekvenich [EMAIL PROTECTED]@main.gmane.org on 10/15/2002 11:20:55 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] Sent by:news [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:Re: DAO or ... ? [Scanned for known viruses] OK, so your formBean would be called via use bean. And the form bean would have some method to do the rest of persistence or populating? OK. That is kid of what I was driving to. One deals with beans. Beans have technology designs (patters) ... but they are there to do bus. requirements (your problem/bus domain patterns/solutions) .V (of course Model 2 is better) [EMAIL PROTECTED] wrote: Model 1? I assume you're referring to the practice of posting directly to a jsp page instead of through an Action servlet - the model 1 that was proposed in the original JSP 0.92 spec. (For those who haven't reviewed it, the JSP 0.92 specificiation was the first place I believe the terms 'Model 1' and 'Model 2' originated. At least that's the earliest I remember seeing it. Here's a link to an old copy of it: http://www.kirkdorffer.com/jspspecs/jsp092.html . It still provides one of the best explanations of the difference between Model 1 and Model 2 that I've come across.). Not sure. I'd suppose you'd create a bean (and access it using a classic jsp:usebean) that is essentially your 'Model' component. This would have to be the equivalent of the 'Form Bean'. You set all the properties on this 'form bean' (using a scriptlet potentially) and then execute some method on it that would invoke this whole back-end process. (there are other potential ways of doing it - this is just one.) The facade and the other statements would be invoked from your bean. Once this processing was done, you could either extract properties from the same bean to populate the 'View', or you could extract another bean (that was a Value Object) from the first bean and drive the display results from it. This actually demonstrates the strength of Struts - the model 1 solution is more complex lends itself to embedding scriptlets faster. Also, a big problem is what do you do when things go wrong communicating to the back end? In Model 1, you have to trap the error and do a jsp:forward or just put conditional processing in the JSP directly - using Struts you simply catch the exception and forward to a different ActionForward. Kevin V. Cekvenich [EMAIL PROTECTED]@main.gmane.org on 10/15/2002 08:43:46 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] Sent by:news [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:Re: DAO or ... ? [Scanned for known viruses] Q: How would you re-use this in Model 1? .V [EMAIL PROTECTED] wrote: James - I've attached a few files from my upcoming book Struts Kick Start that provide a basic design pattern that sounds like it may be similar to what your describing. What I do is: - Create a Value Object that encapsulates data communicated with the Model component. - Create a facade class that accepts and returns value objects through 'business methods'. By defining the facade to work at a 'business method' level, it helps keep any code related to a particular persistence layer or back-end system out of the Action class. This also addresses the issues you described of 'designing to test' - the clean seperation between the Action class and the Model components that the Facade provides simplifies testing. - Create the form bean to provide set/get methods that also accept and return value objects - this greatly simplifies the Action class and isolates it from changes. The Action class (a bit simplified - I've taken out detailed comments and exception handling) goes something like: // cast the form bean CustomerForm cf = (CustomerForm) form; // Create a facade to interface to the back-end system CustomerWSFacade facade = new CustomerWSFacade(); // Extract the value object from the form bean CustomerValueObject cvo = cf.getValueObject(); // Pass the value object to the facade. It returns an update value object cvo = facade.addressChange( cvo ); // Use the returned value object to update the values in the form bean. cf.setValueObject(cvo); These particular classes come from the chapter on providing integration with Axis for Web Services. Another chapter uses the identical set of classes to communicate with JBoss using a Session Bean - all I did was write a different facade class. The point of this was to demonstrate a design that made it very simple to perform maintenance or changes on the back-end or persistence layer. Regarding testing - I'd recommend you take a look at the StrutsTestCase project at sourceforge - it provides some great templates for both JUnit and Cactus
RE: DAO or ... ? [Scanned for known viruses]
James - I've attached a few files from my upcoming book Struts Kick Start that provide a basic design pattern that sounds like it may be similar to what your describing. What I do is: - Create a Value Object that encapsulates data communicated with the Model component. - Create a facade class that accepts and returns value objects through 'business methods'. By defining the facade to work at a 'business method' level, it helps keep any code related to a particular persistence layer or back-end system out of the Action class. This also addresses the issues you described of 'designing to test' - the clean seperation between the Action class and the Model components that the Facade provides simplifies testing. - Create the form bean to provide set/get methods that also accept and return value objects - this greatly simplifies the Action class and isolates it from changes. The Action class (a bit simplified - I've taken out detailed comments and exception handling) goes something like: // cast the form bean CustomerForm cf = (CustomerForm) form; // Create a facade to interface to the back-end system CustomerWSFacade facade = new CustomerWSFacade(); // Extract the value object from the form bean CustomerValueObject cvo = cf.getValueObject(); // Pass the value object to the facade. It returns an update value object cvo = facade.addressChange( cvo ); // Use the returned value object to update the values in the form bean. cf.setValueObject(cvo); These particular classes come from the chapter on providing integration with Axis for Web Services. Another chapter uses the identical set of classes to communicate with JBoss using a Session Bean - all I did was write a different facade class. The point of this was to demonstrate a design that made it very simple to perform maintenance or changes on the back-end or persistence layer. Regarding testing - I'd recommend you take a look at the StrutsTestCase project at sourceforge - it provides some great templates for both JUnit and Cactus tests that are designed for Struts. Makes JUnit/Cactus testing pretty straightforward. A copy of this and detailed directions also come with the book. http://strutstestcase.sourceforge.net/ Best of luck - Kevin Author, Struts Kick Start (See attached file: customer.zip) Couball, James [EMAIL PROTECTED] on 10/14/2002 01:19:16 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To:'Struts Users Mailing List' [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:RE: DAO or ... ? I recommend taking a look at the Session Façade pattern in the Java Blue Prints. No matter if you use EJBs or not, this pattern encapsulates the ideas that Simon was mentioning. Does anyone know the name of the more general pattern that doesn't involve Session Beans specifically? One of my general concerns is design to test. I like to be able to test the (business/persistence) layer that the actions will call independently of struts, actions, etc. Encapsulating that layer in an API (or wrapping with a session bean) makes this possible. Sincerely, James. -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 8:16 AM To: Struts Users Mailing List Subject: RE: DAO or ... ? But you still call the API from the action right - is this not invoking the functionality that persists your data? Seems a bit like semantic juggling to me... (after all the persistance layer is just an abstraction API on top of writing to db/disk/punchcard itself...) ;-) I would however agree that there ought to be some sort of abstracting layer between the view and the implementation specific details of the p-tier... -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 23:04 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: DAO or ... ? You invoke your persistence code in the same place that you would invoke any other code ... not in the Action! Write all your core application code (business rules, persistence, communications etc) in a way that has no connection to the view portion of your system and then create a API to it. This way you can have any client you like call into your core code and your core code doesn't need to worry about what calls it, only about acting upon requests. Then use the actions to call into the API and pass the API return values to the JSPs. Works great. /--\/---\ /\ |Client|-- |API|--|Core| |Code || | |Code| \--/\---/ \/ The API is now your fire break. Nothing on the Core Code side has to worry about displaying anything and nothing in the Client Code has to worry about calculating anything. Simon - Simon P. Chappell
