Hi Rick,
I do #1 and #3 depending on the nature of the field. It keeps the objects
separate.
For objects that are pretty dynamic or don't come from a set list, I'd do #1.
My DTO's know whether a field has been populated or not and throws an error
when the path taken by the request didn’t populate it.
I do a #3 for a more generic "lookup" type object where the values don't
change often (or at all), such as "position" of an "employee" (where a
"position" might have attributes such as pay level, parking area, benefits
package, etc - hard to think of another example right now). The employee's
position might change, but the pay level, parking aread, and benefits package
of any given position won't change much. For such objects, I have a lookup
system that's pretty generic which I use to look them up based on keys (such
as "position" or "departmentId"). It manages several lists, each of which is
individually configured in an XML file and has settings for how often they're
reset or reloaded based on time and/or number of reads. Some lists reset
everyday, some after 100 reads, some after 1 day or 10000 reads whichever
comes first. There's one custom tag which also accepts a key and can
optionally accept the name of the object's attribute to display. So I can do
<my:lookup list="departments" key="${employee.departmentId}"
property="name"/> to display the department name for the employee, and in
almost all cases I don't have to create a separate tag. (Haven't really had
to yet, though I don't discount the possibility. In such a case it wouldn't
be difficult since it'll use the same lookup management object.)
Hubert
--- Rick Reumann <[EMAIL PROTECTED]> wrote:
> Curious about the different ways you guys handle this..
>
> For simplicity, imagine you are needing to return a List of
> Employee objects. Each Employee belongs to a department.
>
> What I debate about is how to handle the creation of the
> Employee Value Object in relation to "department." From a
> business perspective I really only need to worry about an int or
> Integer representing "departmentID", yet for display purposes
> I'll often need to display "dpeartmentName." There seems to be
> several ways to handle this...
>
> 1) Store a Department object (id, name) as a field inside of
> Employee. This is nice from an OO perpsective, but can be a bit
> more difficult to handle depending on the persistence mechanism
> of choice. I tend to think this approach can create a bit of
> unnecessary overhead.
>
> 2) Simply store another field in EmployeeVO as String
> departmentName. I seem to end up doing this because it's simple,
> but it just doesn't 'feel' right. The EmployeeVO only really
> needs to know what departmentID it should have. The
> departmentName is only important for display purposes.
>
> 3) Provide some way for your display to figure out the
> departmentName based on a given departmentId (JSP tag, map
> lookup, whatever). I don't really like this approach because if
> the values can change (in this case Departments), it requires a
> db lookup any time you want to get a departmentName (unless you
> create some guaranteed way to have a cache updated). Plus this
> is only an example and it's just one field, but potentially your
> application can have a bunch of similiar things to deal with -
> do you really want to have to create a bunch of tags or maps to
> deal with this?
>
> 4) Return a List of Department objects and in each of those pull
> out a List of Employees. Awkward to work with (some gymnastics
> to get a complete employees display back ordered correctly).
> Also department could contain tons of fields other than List or
> Collection of Employees. Do we really want a whole bunch of
> Department objects back just to get our employees? This also
> a potential problem in option 1 above as well. Even if all the
> fields of Department aren't populated, it still seems ugly
> having this big object as part of an Employee.
>
> Thanks for ideas on how you guys handle this.
>
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
