Thanks in advance for your patience in reading this somewhat lengthy post. I tried to keep it as simple as I could.
My application tracks the distance users walk along walking routes of their choice. As such, I have a UserDTO and a RouteDTO.
The functions of one of my JSP pages is to display a list of routes. Up to this point, I retrieve a Collection of RouteDTOs and using c:forEach, iterate and display the route information.
The new feature I need to implement is to display a checkmark besides routes that the user has already completed, but only if the user is logged in. Otherwise, the user is just a guest seeing what list of routes is available.
My question is: what is the proper way to pass this data to the JSP page? Do I need to create a new DTO that consists of data from the RouteDTO and UserDTO classes, and create a new method in my UserManager or RouteManager to return this data?
Or, more generally, should I have DTOs that are tailored for each JSP page? Increasingly, I'm finding that the data that specific classes such as UserDTO and RouteDTO (which virtually represent tables in the database) are inadequate for the requirements of complex pages I need to create. But creating new DTOs and corresponding methods in my Manager classes seems awkward and restricts the flexibility of what I can display. For instance, what happens if I write a new DTO that holds the route name and a boolean for completed status, and then at a later stage I need to display more info, like the route description and distance? I'd have to rewrite these classes, the DAOs and the JSP pages, which seems wrong to me.
Any design suggestions or clarification would be very much appreciated. I have been struggling with this issue for quite some time. Thank you.
if you create ViewBeans (equivalent of backend VO or DTO) for each JSP's, you can break down or combine your DTOs into various ViewBeans for your frontend. this way, you keep your objects in the frontend independent of the objects the backend is using, enforcing separtion of concerns. so the answer is yes, you should create new ones, but only specific to the frontend and they are conceptually ViewBeans that the backend classes should not be touching.
-/a<br />certified slacker...yes, my last name is 'do' - <a href="http://www.luckycouple.com" target="_blank" rel="nofollow">luckycouple.com</a>
Alan, your "ViewBeans" sound an awful lot like ActionForms.
A good workman is known by his tools.
Joined: Apr 14, 2005
ah, good buddy, but ActionForms are too specific to struts and are usually not used (well, not physically created by the developer) in the cases where the developers prefer to use DynaActionForms. it's is agreeable though... tomayto, tomaato.
Joined: Sep 02, 2005
Thank you both very much for your responses.
I had this misconception that DTOs applied to the entire MVC model, for both transferring data between my DAOs and Business logic and between the business logic and the View. As such, I thought that I had to create new DAOs (or tag on extra methods to existing ones) to handle the new DTOs I wanted to display. This of course cripples the model and creates dependencies between the data layer and the presentation layer.
I was initially worried about overhead, especially for creating Collections of ViewBeans from DTOs, but now realize that to pass Collections of DTOs to the View I would potentially be wasting memory in holding data that was irrelevant and not going to be displayed anyway. I guess there is a tradeoff.
Originally posted by alan do: ah, good buddy, but ActionForms are too specific to struts and are usually not used (well, not physically created by the developer) in the cases where the developers prefer to use DynaActionForms. it's is agreeable though... tomayto, tomaato.
Agreed with Alan. I prefer DynaActionForms as input, and just regular Java beans (yes, we can call them "ViewBeans") with necessary information for JSP putted in request/session scope.
<a href="http://www.BossTalks.com" target="_blank" rel="nofollow">http://www.BossTalks.com</a><br />Free advices and help for entrepreneurs: from Idea to IPO<br />Software and IT Project Management forum