You could also use a facade pattern. We have one in our Struts app and we're planning on keeping the facade when we move to JSF.
Before you had ... Facade::getInvoice InvoiceForm::setInvoice, etc. InvoiceAction::execute Now you have .. Facade::getInvoice InvoiceBacker::getInvoice If the DAO logic, etc. is hidden behind a facade its resuable as is. That's another approach. I'd be curious to know if anyone else uses this. sean On 8/23/05, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote: > > 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
