You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ke...@sunlife.com on 2002/10/14 20:12:44 UTC
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" <Ja...@cotelligent.com> on 10/14/2002 01:19:16 PM
Please respond to "Struts Users Mailing List"
<st...@jakarta.apache.org>
To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
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:andrew.david.hill@gridnode.com]
> 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:Simon.Chappell@landsend.com]
> Sent: Monday, October 14, 2002 23:04
> To: Struts Users Mailing List; andrew.david.hill@gridnode.com
> 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 simon.chappell@landsend.com
> Java Programming Specialist www.landsend.com
> Lands' End, Inc. (608) 935-4526
>
>
> >-----Original Message-----
> >From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
> >Sent: Monday, October 14, 2002 9:57 AM
> >To: Struts Users Mailing List
> >Subject: RE: DAO or ... ?
> >
> >
> >So where should one invoke the persistance layer?
> >
> >-----Original Message-----
> >From: Lacerda, Wellington (AFIS) [mailto:Wellington.Lacerda@fao.org]
> >Sent: Monday, October 14, 2002 22:51
> >To: 'Struts Users Mailing List'
> >Subject: RE: DAO or ... ?
> >Importance: High
> >
> >
> >Hi Kevin
> >
> >Avoid persistence in Action code as much as you can.
> >
> >This is the general recommendation.
> >
> >Wellington Silva
> >Author of "JSP and Tag Libraries for Web Development"
> >FAO of the UN - Consultant
> >
> >-----Original Message-----
> >From: Kevin Viet [mailto:vietk@activia.net]
> >Sent: Monday, October 14, 2002 4:45 PM
> >To: struts-user
> >Subject: DAO or ... ?
> >
> >
> >My question is a web app design question.
> >What pattern you guys follow when you want to save a domain object in
> >the database ?:
> >
> >- use the DAO pattern of java blueprint (persistence layer is called
> >into classes)
> >- call to persistence statements into action code :
> >
> > // store example
> > try {
> > PeristenceLayer pl = getPerstitenceLayer();
> > pl.save(domainObject);
> > }
> > catch (Exception
> >
> >
> >--
> >Kevin Viet <vi...@activia.net>
> >ActiVia Networks
> >
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> ><ma...@jakarta.apache.org>
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> ><ma...@jakarta.apache.org>
> >
> >
> >--
> >To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <mailto:struts-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <
mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <
mailto:struts-user-help@jakarta.apache.org>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
Re: DAO or ... ? [Scanned for known viruses]
Posted by "V. Cekvenich" <vi...@users.sourceforge.net>.
Q: How would you re-use this in Model 1?
.V
Kevin.Bedell@sunlife.com 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" <Ja...@cotelligent.com> on 10/14/2002 01:19:16 PM
>
> Please respond to "Struts Users Mailing List"
> <st...@jakarta.apache.org>
>
> To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
> 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:andrew.david.hill@gridnode.com]
>>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:Simon.Chappell@landsend.com]
>>Sent: Monday, October 14, 2002 23:04
>>To: Struts Users Mailing List; andrew.david.hill@gridnode.com
>>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 simon.chappell@landsend.com
>>Java Programming Specialist www.landsend.com
>>Lands' End, Inc. (608) 935-4526
>>
>>
>>
>>>-----Original Message-----
>>>From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
>>>Sent: Monday, October 14, 2002 9:57 AM
>>>To: Struts Users Mailing List
>>>Subject: RE: DAO or ... ?
>>>
>>>
>>>So where should one invoke the persistance layer?
>>>
>>>-----Original Message-----
>>>From: Lacerda, Wellington (AFIS) [mailto:Wellington.Lacerda@fao.org]
>>>Sent: Monday, October 14, 2002 22:51
>>>To: 'Struts Users Mailing List'
>>>Subject: RE: DAO or ... ?
>>>Importance: High
>>>
>>>
>>>Hi Kevin
>>>
>>>Avoid persistence in Action code as much as you can.
>>>
>>>This is the general recommendation.
>>>
>>>Wellington Silva
>>>Author of "JSP and Tag Libraries for Web Development"
>>>FAO of the UN - Consultant
>>>
>>>-----Original Message-----
>>>From: Kevin Viet [mailto:vietk@activia.net]
>>>Sent: Monday, October 14, 2002 4:45 PM
>>>To: struts-user
>>>Subject: DAO or ... ?
>>>
>>>
>>>My question is a web app design question.
>>>What pattern you guys follow when you want to save a domain object in
>>>the database ?:
>>>
>>>- use the DAO pattern of java blueprint (persistence layer is called
>>>into classes)
>>>- call to persistence statements into action code :
>>>
>>> // store example
>>> try {
>>> PeristenceLayer pl = getPerstitenceLayer();
>>> pl.save(domainObject);
>>> }
>>> catch (Exception
>>>
>>>
>>>--
>>>Kevin Viet <vi...@activia.net>
>>>ActiVia Networks
>>>
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><ma...@jakarta.apache.org>
>>>For additional commands, e-mail:
>>><ma...@jakarta.apache.org>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><ma...@jakarta.apache.org>
>>>For additional commands, e-mail:
>>><ma...@jakarta.apache.org>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:struts-user-
>>unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:struts-user-
>>help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <
> mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <
> mailto:struts-user-help@jakarta.apache.org>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------------
> This e-mail message (including attachments, if any) is intended for the use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt from
> disclosure. If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify the sender and erase this e-mail message immediately.
> ---------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>