+ 0 Mike. I show the methods 1-3 when I teach and in my 2nd Struts book.
Then I teach formBean has a DAO helper (is a/has a)
In action you just say: formBean.populate(req.getParm);
And then in baseFormBean: populate(Object o) { myDao.populate(XX); // populate DAO from DB _list = myDao.getData(); // copy data from DAO to formBean. }
This way you can reuse your layers. (So you have nice noun.verb();)
I can now unit test Model (MVC layers benefit is that I can unit test a component), use in JSTL, re-use in Model 1, javascript, console apps (for asyn. acces).
All the action should be used is to decide where to go to next based on (error?) conditions.
.V
Mike Duffy wrote:
I would suggest option 1, with a slight variation.
I think it is best to keep action classes as lean as possible. Rather than doing any heavy lifting in an action class it is better
to make calls to delegates and other helper classes. The modular
nature of the code enhances code reuse and maintainability. Also,
the system becomes more flexible.
With this said, rather than "Have the action class copy information from the form to a value object.", IMHO it is better to make a call to a method in a factory class that takes in an action form and returns a value object.
Within the factory method, I would highly recommend use of the method BeanUtils.copyProperties(java.lang.Object dest, java.lang.Object orig)
You may be able to use the copyProperties method to completely copy your action form to value object, but in all but the most simple cases you will probably need to do some additional massaging based on selections made in the web interface.
As a simple example, if you have a web interface for user registration with a corresponding UserActionForm and UserValueObject, you would pass an instance of the UserActionForm to the method createFromActionForm in the UserFactory class. This method would return a UserValueObject which could then be passed to a DAO object for persistence.
The UserFactory might also have other create methods that would
create users from sources other than a web interface (comma delimited
text file, etc.).
In this simple example, it might seem like overkill to create a
factory class to process a simple user form; however, as an
application becomes more complex keeping to a design pattern that
everyone uses truly enhances the quality of life (IMHO this is the
greatest advantage of Struts; an advantage not easily seen in simple
systems, but readily apparent in complex systems.).
A more complex example would be the processing of energy data from a
web interface and from several several different corporations and
state agencies. The factory classes are the focal point for creating
value objects from different resources.
Mike
--- Andrew Hill <[EMAIL PROTECTED]> wrote:
---------------------------------------------------------------------2 & 3 generally end in tears. They sound nice, but when you get down to the fiddly bits you will find it more problematic than you expect.
As you mention, the action form is very much a view object. For a start everything in the actionForm will be strings, while your business object probably will not be. Secondly, while there is considerable overlap between your value object and your form, you will find (especially as your ui gets more complex) that the correlation is not 1 to 1 and that you are exerting a lot of effort to try and keep the two the same.
Approach 3 is probably the worst - unless its for read only display - in that if the user enters a value that doesnt convert to your value objects property type you will want to redisplay the offending value string the same as the user typed it for them to correct it.
Your best bet is to use approach 1. You may be interested to note that the BeanUtils class does have some methods that can make life simpler for you - copying property values and doing type conversions automatically (if I recall correctly).
(Actually I generally copy the properties the 'hard' way, one by one in my action)
-----Original Message----- From: Jordan Reed [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 12:29 To: Struts Users Mailing List Subject: Populating Value Objects for the Business Tier
All,
I'm on a team that's trying to decided on a best practice for passing on populating our value objects that get passed to our business layer. We currently have three techniques we've though up and I'm wonderful if anyone has a strong opinion on which one may be the "best" and why.
The basic problem is that the user enters information into a form. The form
is a presentation object, and should not be passed to the business
layer.
So it's information needs to be in a presentation-agnostic
interface before
being passed to the data layer.
1) Have the action class copy information from the form to a value object. Have a view helper copy information from the value object into the form (for pre-population)
2) Have the form implement a value-object-like interface. The business layer accepts objects with these business interfaces. This way it is possible to pass the form objects to the business layer without the business layer knowing that they are presentation objects.
3) Have the form simply include value objects as properties. Then
use the
nested taglibs to populate the value objects. This way the Action
can just
pull the value object off directly and pass to the business layer. A view
helper can just set the value object on the form.
-jdr
---------------------------------------------------------------------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!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
-- Vic Cekvenich, Struts Instructor, 1-800-917-JAVA
Advanced <a href ="baseBeans.com">Struts Training</a> and project recovery in North East. Open Source <a href ="baseBeans.com">Content Management</a> basicPortal sofware
Best practice<a href ="baseBeans.com">Struts Support</a> v.1.1 helper ScafflodingXPress
