struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V. Cekvenich">
Subject Re: How closely to map VOs/ActionForms to relational DB?
Date Wed, 22 Jan 2003 12:40:06 GMT
-That sounds like a very good class Craig. I can't wait to use it, 
sounds similar to disconnected row set, when used with commons-sql for 
persistence (at least that is how I will use it).

-David, with respect, view do not ease join problems but hide it. Also, 
sometimes you can use selection/options collection on browser and cache 
and not join on server.

- Tevor, what I do as far as objects is I have formbeans that *MUST* 
match my view/jsp/requirment of course. That is #1.
#2. Then I look to see if its a submit/updetable. Most of the time its not.
So if no submit, no "form bean" in struts-config.
That means I would write long join and have one or several beans defined 
in request. Joins (but try to speed up with options/collection*) and 
multiple beans defined in scope.
#3. If it is updetable/submit, I define a formbean in Struts config.
(You can only have one) and nest. Your back end now has to map close to db.

So a short answer to Tevors question, imo, "how closely should the back 
beans match the jsp?"  is match db on updetable formBeans, and  match 
the jsp when no update with joins/mutiple beans.

Struts project recovery/mentoring

* OT: If you want to show employee and departments and status. Do not 
join to department and status, just have a select optionsCollection in 
say application scope. That is because when employ changes departments 
or status, only employ table changes. Anyway, for performance and 
validation, use lot's of select options collection.

Craig R. McClanahan wrote:
> On Tue, 21 Jan 2003, David Graham wrote:
>>Date: Tue, 21 Jan 2003 18:10:33 -0700
>>From: David Graham <>
>>Reply-To: Struts Users Mailing List <>
>>Subject: Re: How closely to map VOs/ActionForms to relational DB?
>>Use views to ease your join problems.  If a person can have many accounts
>>then I will have a Person object in each account object but I won't have a
>>list of accounts in the person object.
> If you don't need your VOs to actually be JavaBeans, you might want to
> look at a recent addition to commons-beanutils (included in the 1.6
> version that was just released, so it'll be included in Struts 1.1 final)
> called RowSetDynaClass.
> What this does is copies the data from an SQL query (either a ResultSet or
> a RowSet) into a List of DynaBeans that can then be manipulated via
> BeanUtils and PropertyUtils methods.  This way, you don't care how many
> different combinations of column names all your different queries might
> require - you are essentially creating a VO dynamically on the fly with
> just the right set of properties.
> Javadocs:
> Craig

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message