Hey Rick - I use a combination of #1 and #2. NEVER #3 or #4.
#1 happens a lot especially when 'stars' appear in your schema, ie where you start finding that you are pulling everything out by EmployeeId. A persistence mechanism isn't an issue for me as I have always ended up building my own - none of the prebuilt ones seem to provide enough flexibility. #2 happens when you have just one field that you need to bring into a VO from a junction or lookup table adjacent to your table. For instance, if an employee has a type table, and that type has a label, I might just add the type to the employee object. So for your specific problem, I would go with #1 and put a department object on an Employee. If you give me more information on what your schema and use cases are, I can help you with the persistence layer. HTH, Alan -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 11:23 AM To: Struts Users Mailing List Subject: best practice question for certain VO/DTO fields? 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
