Yes,
but we've found that, for us anyway, that allows better mixing and
matching. For example, we have a session-scoped UserBean that is used by
all Actions, and some other beans that are shared between certain action classes
but not others. That way, our beans and action classes are pretty lean,
and it's easy from a maintenance perspective to determine which data elements
are relevant to which actions.
But,
as Martin Mentioned, JSF allows one to roll everything up into one huge class,
disperse them out, or do something in between.
For
example, the one time that we do combine actions and data is in using the
TreeBacker in Tree2, because that's when we do lazy fetches of data as the user
is expanding the tree. So, in that case, the action methods and data
are tightly coupled and special purpose.
-
Brendan
-----Original Message-----
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 23, 2005 4:24 PM
To: MyFaces Discussion
Subject: Re: confusion on best practices in regard to a VO in BackingBean
On 8/23/05, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote:--As another alternative, the practice we've been following is to have an
XyzAction class and a separate XyzBean class. The Action class has a
managed reference to the Bean class and has all the logic in it. The
Bean class is just a straight JavaBean and contains all the data needed
by the JSF page.
In the above case wouldn't you need to end up registering both XyzAction and XyzBean as managed beans? It would seem like you would have to. I guess not a big deal, but you'd end up with double the number of typical backing beans.
Rick
