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 > 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 [EMAIL PROTECTED] > > Java Programming Specialist www.landsend.com > > Lands' End, Inc. (608) 935-4526 > > > > > > >-----Original Message----- > > >From: Andrew Hill [mailto:[EMAIL PROTECTED]] > > >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:[EMAIL PROTECTED]] > > >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:[EMAIL PROTECTED]] > > >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 <[EMAIL PROTECTED]> > > >ActiVia Networks > > > > > > > > > > > > > > >-- > > >To unsubscribe, e-mail: > > ><mailto:[EMAIL PROTECTED]> > > >For additional commands, e-mail: > > ><mailto:[EMAIL PROTECTED]> > > > > > > > > >-- > > >To unsubscribe, e-mail: > > ><mailto:[EMAIL PROTECTED]> > > >For additional commands, e-mail: > > ><mailto:[EMAIL PROTECTED]> > > > > > > > > >-- > > >To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > To unsubscribe, e-mail: <mailto:struts-user- > > [EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:struts-user- > > [EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > -------------------------------------------------------------- > ------------- > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
