You can check the latest version of Strut by Strut. There are some
"stub" versions of what I use for value object there. Though, my
implementation is rather straight-forward, since I am not trying to hook
these up with enterprise beans, just use the same general design
pattern.
As a convenience, I've started to merge the data access object into the
value object bean, so that the value bean knows how to insert, select,
update, or delete itself. (But only through internal methods, there are
no public mutators on the value beans.) The data access is provided via
an "Accessible" interface to keep a clear distinction between the value
methods and the data access methods. Likewise, I would also added
another interface to represent and seperate business logic that needed
to use this data.
Again, the core idea is to simply use ActionForm beans to get stuff on
and off HTML forms, and then use your own framework-independant beans
for everything else.
Jonathan Asbell wrote:
>
> Great explanation Ted. I am interested in your implementation of the
> ValueObjects. It appears as though you dont use the ActionForm as a value
> object, but rather pass the ActionForm beans values on to the value object
> after validating symantics in the Action. Is this true? I ask because I
> have read 3-4 different ways to implement the value object, and I am
> interested in what works best with struts. You remember the comment by
> Bryan Field-Elliot? He wrote me with his implementation which he felt he
> still had to work out some issues with hiding some data from other classes.
> I then read an interesting idea at theserverside.com
> http://www.theserverside.com/patterns/thread.jsp?thread_id=2722 and another
> version http://www.theserverside.com/patterns/depbmp.jsp.
>
> ----- Original Message -----
> From: "Ted Husted" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 30, 2001 10:38 PM
> Subject: Re: Bean philosophy
>
> > Jonas Bjornerstedt wrote:
> > > I see little reason (yet) why the ActionForm should be modeled as such.
> >
> > I think the keyword here is "yet". Much of the underlying Struts designs
> > are based on trends and patterns that have yet to reach their logical
> > conclusion.
> >
> > For example, future Java design tools are sure to fully support
> > JavaBeans. Support for other structures, like hashtables, is likely to
> > be less thorough. Another example is custom tags, which are a good thing
> > now, but will be a truly tremendous thing when the visual HTML editors
> > catch up with the Java 2 spec.
> >
> > Struts is also designed to work well with J2EE design patterns, which
> > rely on JavaBeans. I construct both my form and model (or value) beans
> > at the same time (using simple search and replace templates), and then
> > extend the value beans to work with native types. Personally, I find it
> > more convenient to be working with beans on both sides, rather than with
> > a hashtable here and a JavaBean there.
> >
> > It is also very important to note that the ActionForm beans are just a
> > means to an end. They exist as an adaptor between the HTML forms and the
> > rest of your application. After the data has been captured, it should be
> > handed to another object to handle the business-logic portion of your
> > program. As such, they are usually only persistent for the life of a
> > request, and as you say, should do little beside validating the input
> > and converting the data for use by another object.
> >
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel 716 737-3463.
> > -- http://www.husted.com/about/struts/
> >
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
