Craig,
My understanding from what you responded me about ActionForm being EJBs was
wrong, sorry about that. However, your explanation in the last email was
extremely useful.
Thanks,
juan
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 10, 2000 4:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Design question
Juan Gargiulo wrote:
> Craig,
>
> Thanks a lot for your answer.
> I think that I'm very close of defining the architecture for my
application.
> Using action classes as adapters and session EJBs for business logic
sounds
> good.
Yep.
> Also using EJBs as actionforms is a good idea because they are a good
> target for object reuse. But it is not clear to me how do this. I don't
see
> how struts is going to know how to get one of this EJB-actionforms from
the
> context. How I specify the name of the home for the EJB-form to the action
> class (to the struts descriptor)?
>
Actually, I do *not* believe it is a good idea to re-use an EJB as an
ActionForm. In fact, this will be somewhat more difficult in 1.0, now that
ActionForm is a class rather than an interface.
The reasoning behind my belief goes like this:
* An ActionForm is part of the view layer of MVC, not the model
layer like an EJB (or a regular JavaBean that represents
persistent data).
* The sole purpose of an ActionForm is to maintain the state of
all the input variables on a particular form, so that you can
reproduce the form pre-filled-in if the user made an error that they
need to fix. This matches the expectations of users who are used
to GUI-based client server apps, that never make you retype any
input except the stuff you did wrong.
* Because of the above, the "domain" of an ActionForm does not
necessarily match any existing EJBs or model layer JavaBeans.
It is not uncommon to have inputs from a single form that will
ultimately cause updates to more than one undelrying EJB or
model bean.
* Using a separate class for the ActionForm means you can
change the underlying organization of your model beans or EJBs
without impacting the view layer (although there might be modest
impacts on the Action classes that copy things back and forth).
* In addition, most EJBs and model beans have validation rules
internally that prevent them from accepting semantically invalid
data. Such rules would prevent you from accomplishing the
primary purpose of an ActionForm -- storing all of the user's
input fields, so that you can reproduce the input screen.
* Also, if your form is multiple pages and you were using the real
EJB, let's say you start updating properties based on receiving
the first page. Now, you've potentially started locking resources
in the underlying database -- and you have to deal with the fact
that the user may never come back and finish this transaction.
So, my bottom line recommendation is that you plan on building simple
JavaBeans
for your ActionForms. Most of the time, an ActionForm will have just
getters
and setters, with no error checking (other than a validate() method if you
want
to use it, plus the reset() method). PropertyUtils also has a convenience
function that can copy properties with like names from your EJB to the
ActionForm bean (or vice versa), to reduce the amount of tedious code that
this
approach implies. And, at some future point, it's reasonable to expect a
development tool to be able to auto-generate ActionForm beans for you.
Using an EJB as a bean that provides data values used in the presentation,
on
the other hand, is pretty easy. Just store the client-side instance you get
back from the EJB server as a request attribute or session attribute -- from
the
perspective of the Struts custom tags, this EJB just looks like a JavaBean
with
getter methods, so they don't care that it is really an EJB. NOTE: If the
EJBs
are really on a remote server this could have some performance impact -- you
might be better served to copy data into local beans in that case.
>
> Thanks,
>
> juan
>
Craig
