This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes Session Bean + DAO Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Session Bean + DAO" Watch "Session Bean + DAO" New topic
Author

Session Bean + DAO

Tomchi Tang
Greenhorn

Joined: Apr 25, 2003
Posts: 15
Hi,
I am desinging an application where I am using Fast Lane Reader Pattern (Stateless Session Bean + DAO) for reports. We have created seperate custom DTOs (Value objects) for each report. Now my question is - where should we place the logic to create the DTOs. Should we create the DTO in the DAO layer and return it to the session bean or create it in the session bean and fill it there. According to Core J2EE patterns, the logic to create the DTO should go in the DAO. I guess this is a good idea when we have to create domain DTOs (the data from one single table), where one single call to the backend will return all the data related to the DTO. But in our case where we have to fire a seperate sql for each DTO field, I think, the logic should go in Session Bean. I am a bit confused. I would like to hear some expert views on that.
Thanks
Tomchi
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8903

Create the DTO in DAO.


Groovy
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I think it would be best to keep *all* SQL stuff inside the DAO layer.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Tomchi Tang
Greenhorn

Joined: Apr 25, 2003
Posts: 15
Thanks for your Input. Actually we want to show different reports which have details like
- Total no of Sellers
- Total no of purchase/non-purchase items and their values
- Total no of categorized/non-categorized items and their values
....
....
This information is also required in other reports. I can think of following possible solutions:
1) Create a generic ReportDAO which have queries used in all the reports. When we need to show a specific report, we can call the ReportDAO from our session bean, fill the XXXReportDTO and send it back to the client.
2) Create a generic ReportDAO which have queries used in all the reports. In addition to these queries, DAO also have functions to create, populate and return specific DTO. In this case, Generic ReportDAO will aslo work as what you called "Super DAO". It interact with session bean and internally use query functions to create and populate DTOs.
3) Similar to (2) where the superDAO will be a seperate Factory Class.
4) Create report specific DAOs which have a method to create report specific DTO.
Pls. suggest which option is the best.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
How about starting out with the one big report DAO and refactoring afterwards if deemed necessary?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Session Bean + DAO
 
Similar Threads
getting data from 2 tables using 2 DTOs
JEE5 Application Architecture Best Practice.
Design Issue : Can I expose DTO through Interface?
where to create DTOs
Interfaces in Component Diagram