Rick, couldn't you use a lazy loading scheme such that the Department reference in each Customer is not "loaded" until accessed and even when the Department is "loaded" only the primary Department data is loaded (no object references). So in essence, you only get what you need, when you need it.
robert > -----Original Message----- > From: Rick Reumann [mailto:[EMAIL PROTECTED] > Sent: Monday, March 29, 2004 1:11 PM > To: Struts Users Mailing List > Subject: Re: [OT] RE: best practice question for certain VO/DTO fields? > > > On Mon, Mar 29, 2004 at 10:42:07AM -0600, Hookom, Jacob wrote: > > > 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. > > Well, it's not the view objects that I'm concerned with per > se. In other words your approach above still has to address > my main concern of what to return in the domain layer. > > From an OO standpoint nesting a Department object inside of > an Employee makes sense. Then, however, I look at it from a > practical standpoint - for example returning a large > Collection of Employees. If the Department object is a large > object you now have all the extra overhead of Department > objects nested inside each Employee. This isn't too big of a > deal if your business 'knows' that it only needs to populate > a few fields in Department (say id, and deptName), but if you > took a more generalized approach of populating everything in > Department, your Employee beans become extremely heavy. > > And if you don't take the generalized approach and your > queries do know exactly what the need to populate for the > view, then it's not a big deal to tack on a few extra fields > in the Employee Value Object. > > I still don't see the need for an extra "EmployeeView" > object. I already would have an EmployeeVO and an > EmployeeActionForm. I don't see what the EmployeView object > would give you compared to using the VO. If it's formatting > concerns JSTL can handle all of that for me. > > -- > 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]
