This has been discussed lots before; I usually opt for ViewObjects that match what is needed for rendering. It makes it really easy to make modifications in the controller as to how the data is pulled while keeping the view unchanged.
EmployeeView.getName() EmployeeView.getDepartmentName() EmployeeView.getDepartmentId() ..... Then your action can initially do whatever you want for proper OO with a domain model or whatever, but if you need to refactor later, you can have that EmployeeView be generated straight from a ResultSet. -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 10: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]
