Thanks for the reply.
Just a couple comments: if the ActionForm parameter in perform() had been
Serializable instead of ActionForm, we wouldn't have this dependency
issue. But then we wouldn't get the benefits today's ActionForm provide.
Another point which is quite obvious from your reply: the validate() in
ActionForm should only do presentation level validation, such as making
sure a string representing age value is all numerical. More business logic
related validation should be done in the upper layer.
Thanks,
Siping Liu
"Craig R. McClanahan" wrote:
> On Wed, 14 Mar 2001, Siping Liu wrote:
>
> > Hi everyone,
> >
> > It seems to me that to better layer an application that uses
> > web/Struts as one of several ways to access its data, the data
> > layer shouldn't have any dependency on the access layer.
> > Currently all my beans have to implement ActionForm (Structs 0.5.
> > I understand that in 1.0 it becomes an abstract class). Let's
> > say I want to make some API's to access the beans and give the
> > API's to others, I have to send struts jar files along?
> >
>
> If you want to use exactly the same ActionForm bean classes, you would
> have to send struts.jar along -- which is fine from a license point of
> view, but not necessarily what you want to do.
>
> My view (which is not necessarily shared by everyone who uses Struts) is
> that ActionForm beans are part of the "view" layer, not the
> "model" layer. Therefore, they have every right to be specific to the
> environment in which they are being used.
>
> JavaBeans that actually represent your model data (either real JavaBeans,
> proxies for things accessed remotely, or EJBs) would *not* be dependent on
> Struts APIs. These are the beans that would be portable to other
> environments.
>
> You will also find that the data types of properties in an ActionForm
> should generally be strings, rather than numbers (so that you can fulfill
> one of the primary purposes of ActionForm beans -- redisplay what the user
> typed along with an error message when validation fails). Thus, you will
> find that there will be differences between your form beans and the
> underlying model beans that they represent, even if there is a one-to-one
> correspondence between the beans themselves, and the properties they
> contain.
>
> > Thanks,
> > Siping Liu
> >
> >
>
> Craig McClanahan