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]
