Thank you to both Kevin and Steven for the advices.
This makes me better for doing the correct design
-D
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, October 16, 2002 12:22 PM
Subject: Re: FormBean Vs ModelBean dilemma
Another suggestion would be to consider your approach of:
1 page = 1 form bean = 1 model object.
I suggest that it's likely you could use less than 20 model components. In
fact, it's probably unlikely that you would model the business as having 20
model components except for the fact that you began with 20 pages.
In other words:
- Define model components at the 'business object level', for example
'Employee', 'Customer', etc. Avoid model components like, 'Customer Address
Page Model'.
- Define methods on the Model Components that match business operations
such as 'Update Customer Address Info'. It's likely that these business
methods would match closely to your JSP pages. That is, you might have
'business method's for each of your 20 pages spread among your various
model components.
Tying your model components so tightly to your view components means that
whenever you change one, you'll have to change the other.
You may or may not have good luck cutting down the number of form beans.
Sometimes it's appropriate for one form bean to serve multiple pages,
sometimes not.
Best of luck,
Kevin
-------------------
Kevin Bedell
Author, Struts Kick Start
"David Graham" <[EMAIL PROTECTED]> on 10/16/2002 02:37:47 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: Re: FormBean Vs ModelBean dilemma
I don't see anything wrong with your setup. Keep in mind that the reason
you have 2 hierarchies is so your business layer doesn't know what
environment it's running in. You can reuse your model beans in a swing
application with no changes. The form beans are only used in a struts web
environment.
You could pass your form beans directly into your business layer but that's
not very elegant and will be frowned upon by most architects.
David
>From: "Dan Tran" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: FormBean Vs ModelBean dilemma
>Date: Wed, 16 Oct 2002 10:20:37 -0700
>
>Hello,
>
>I am seeking for some advice on the best way to implement my project
>
>I have a bout 20 screens to display and persist into DB.
>I follow the tutorial on
>
>
>http://www.keyboardmonkey.com/pilotlight/next/Tutorial_partTwo.jsp?content=
y
>esplease
>
>and implemented my prototype and ended up with 2 similar java object
>hierachies. One for the
>form bean and one for the model bean. As recommend by all expert on this
>list as well as Chuch's book,
>All action form bean's properties are String, the actionform beans are
copy
>to the model beans to be persisted.
>
>The dilemma here is I have 2 similar groups of objects (and lots of set
and
>get methods to type) and scare the hell out
>my boss ;-)
>
>Any suggestion?
>
>-Dan
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
_________________________________________________________________
Unlimited Internet access -- and 2 months free! Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
