Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: struts-user@jakarta.apache.org
Message-ID: <3B31E279.4545DBA4@apache.org>
Date: Thu, 21 Jun 2001 08:03:05 -0400
From: Ted Husted <husted@apache.org>
Organization: Apache Software Foundation / Jakarta
MIME-Version: 1.0
To: struts-user@jakarta.apache.org
Subject: Re: [EJB] Design Patterns (was JavaReport ...)
References: <079FD72E42C9D311B854009027650E6F059E6C8C@xatl02.atl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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