-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.
Vic
Struts project recovery/mentoring
http://strutsplus.com/
[EMAIL PROTECTED]
* 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 <[EMAIL PROTECTED]> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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: http://jakarta.apache.org/commons/beanutils/api/DavidCraig
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
