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 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
