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]
