On Wed, 13 Jun 2001, Ryan Cornia wrote:
> In the struts-example, there is an OrganizationForm, and an
> Organization bean. They have identical fields and getters and setters.
> Why is the logic duplicated in both places? Couldn't OrganizationForm
> extend Organization, or "have a" organization bean in it that you
> could reference from a form somehow? This seems like a lot of
> duplication that doesn't add value.
>
> Am I missing something here?
>
> Ryan
>
>
>
The key issue is that the two objects have different purposes.
Organization is a "data access object", representing the real live
information in your database. As such, you do not want to be making any
changes to it unless you've validated that those changes are correct.
There will typically be one "Organization" style class per different
business object in your database, possibly with pointers to other business
objects as well.
OrganizationForm is required to be a subclass of ActionForm, and it is
really part of the "view" layer of an MVC architecture. It's primary
purpose is to be able to reproduce the input that the user typed, if
validation fails and the user is returned to that particular input form
again.
Consider what would happen if you've got an integer property in your
database object (not true with Organization, but very common in real
life). The corresponding property type on your data access object would
undoubtedly be an "int". But you would *not* want to do this on your
OrganizationForm bean. You want the property to be a String instead.
Why? Consider that the HTML representation of the input field lets the
user type anything they want, and say your user types "1A3". You want
your form bean's validate() method to be able to catch this, create an
appropriate error message, and -- when the user is returned to the input
form again -- have the field pre-filled-out with "1A3" (exactly what the
user typed). This is a standard user expectation based on the way GUI
programs work, and web apps that violate this expectation will get low
marks for user friendliness.
Another consideration is that a data access object will typically contain
properties for all of the underlying database information, while form
beans need to have only the properties that are required for this form.
Different developers take different views of whether a form bean should
include all the properties (I tend to be a minimalist, and only define
properties for the fields actually on the form), but having different
objects that are not in the same inheritance hierarchy gives you the
option to mix and match as needed.
Craig
