What you have here is:
1) an immutable from the web tier
2) an immutable from the enterprise tier
3) a need to update each other
Maybe they are immutable as far as standard get/set methods.
However, they can also implement an interface which uses separate secondary
fileds which start with the original values, and CAN be updated. In this
way the 2 original models (the web tier ActionForm and the EJB model) can
have the original values untouched, and the new secondary fields will hold
and provide the updated state.
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 8:03 AM
Subject: Re: [EJB] Design Patterns (was JavaReport ...)
> What I'm working on now are patterns for Struts development that can be
> used with or without Enterprise Beans. As mentioned, the J2EE blueprints
> are mostly about development patterns, and Enterprise Beans are one part
> of implementating those patterns. This work is the second part of the
> Strut by Strut series ("Stepping out").
>
> I had a long discussion with a BEA Weblogic employee the other day about
> this very thing. I think we need to more strongly seperate the J2EE
> patterns from the Enterprise Bean implementation. The idea being we
> should introduce people to the pattern first (presentation beans / data
> access beans / value object beans / helper beans), and then show where
> Enterprise Beans plug into that. Or, where you would roll your own.
>
> On the Struts front, while it is often the case that the ActionForm
> beans end up looking like many of your internal beans, there are
> important differences. For example, ActionForm beans should be immutable
> except by the actor, meanwhile many of your internal beans should be
> immutable except by the model. ActionForm beans need to use Strings as
> the primary type, but your internal beans may need native types to
> commune with the business logic beans. You really only need ActionForm
> beans to get input from the actor. When sending read-only views back,
> you can use any kind of bean you want (with the bean tags), so long as
> it has a reasonable toString(). It seems wasteful at first, but in the
> big picture, it seems like treating ActionForm beans as HTTPD
> throw-aways is the only way to keep the application loosely coupled, and
> able to attach to other environments later.
>
> Of course, data transfer becomes a big issue when you have to ferry
> things from ActinForm beans to data-access beans (and then back again in
> the case of an update). What I'm looking at now is using hashmaps as a
> standard data transfer agent. If the ActionForm can return a hashmap
> that matches the data access bean you can use BeanUtil.populate() to
> make the switch. Coming back later, if the value object bean returns a
> hashmap, you can use BeanUitl.populate() to fill your ActionForm bean
> (for an update). This would mean that your ActionForm bean design
> "knows" about your value object bean design, but I think that's OK
> (though the inverse would not be OK).
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
>
> "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" wrote:
> >
> > To Anyone It Concerns,
> >
> > Although I'm relatively new to EJB's, I'm listed on the 1.1 TODO list
> > to add better EJB support/design patterns. Ideas that anyone has about
> > things that they'd like Struts to do with EJB's will definately help me
> > along with this and help Struts quiet this EJB fud. I'm looking to get
> > started on this soon, and anyone who wants to is more than welcome to
> > help me out.
> >
> > - Mike
>
