+1. Take a look at http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf
more specifically these patterns: Data Transfer Object Factory Custom Data Transfer Object robert > -----Original Message----- > From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > Sent: Monday, March 29, 2004 11:42 AM > To: 'Struts Users Mailing List' > Subject: [OT] RE: best practice question for certain VO/DTO fields? > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
