DAO/DTO help
Hi,
I have been struggling quite some time now with a certain DAO/DTO question.
I have been looking all over the web but found no satisfying answer. What I did find was a forum post which formulates my question exactly:
Where does your DAO/DTO implementation draw the line?
For example:
Let's say I have three tables:
Employee (contains employee_id, employee_name, and dept_id)
Department (contains dept_id, dept_name, loc_id)
Location (contains loc_id, location_name)
How deep do your classes go to replicate the data?
Do you do this...
public class Employee {
private int id;
private String name;
private int deptId; // just the id
// .. implementation details
}
or do you do this
public class Employee {
private int id;
private String name;
private Department dept; // all of the data
// .. implementation details
}
and so on and so on. Class Department has the same type of problem.
Does it hold just the id for location or a variable class Location?
Should DAOs just fill in the id (keys) so it is up to the application
using the DAOs to get the Employee class, then the Department class,
and the the Location class like:
Employee emp = EmployeDAO.getEmployee(1);
Department dept = DepartmentDAO.getDepartment(emp.getDeptId());
Location loc = LocationDAO.getLocation(dept.getLocId());
System.out.println(emp.getEmpName() + " works in " +
loc.getLocationName());
or
Employee emp = EmployeDAO.getEmployee(1);
System.out.println(emp.getEmpName() + " works in " +
emp.getDept().getLoc().getLocationName());
Now this is just a simple example, but where do you draw the line?
It's possible to go on and on and on and cycle back to employee...
What if I have an employee search screen that wants to show only some
of the information of an employee (not all). What do you do then?
1. Instantiate an Employee object and only fill in the relative
information? Keep in mind that this could be just employee name and
location on the search results screen and then when the user chooses
which employee to view I need to get all of the employee information.
2. Instantiate an Employee object and fill out all the information
even though you won't be needing most of it on the search results
screen?
3. Create 2 DTOs, one called Employee and one called EmployeeSearch
DTO. The EmployeeSearch DTO only stores what needs to be shown on the
search results screen and the EmployeeDTO holds all the information
for what needs to be shown on the detail screen?
4. Something else...
Thanks!
It's up to you for the most part. DAO and patterns are just guidelines. At any rate, I don't see how storing JUST the id would be at all useful. Typically if you have a table called employee with 5 columns, you usually have a DAO object with 5 properties. If you ONLY need to display 2 of those properties (after reading from the database) you can ignore the other 3 properties. If you NEVER use those other 3 EVER, you can just populate the 2 properties and don't bother defining useless stuff in the DAO.
This was a very simple example to demonstrate my problem. In reality it is much more complex. Therefor I am looking for the best practice on how to deal with a situation like that.
I appreciate your answer very much, but I would like to understand WHY something is usefull, and WHY it is better to choose one tactic above another. I realise it isnt that simple and depends on the actual situation, yet I am trying to broaden my horizon and learn from experienced people like you.
In my opinion (more or less) each table in a database has a corresponding DAO (Data Access Object) which manages that table (Create Read Update Delete). The DAO uses a corresponding DTO (Data Transfer Object). The DTO is just an image of that table (just getters and setters for each column of that table - nothing else).
Then I encounter a problem: what if I need to show a list of data which come from multiple tables. The regular DTOs arent sufficient.
In that case I create a specialised DTO which contains that data for me. And maybe a specialised DAO for serving those specialised DTOs?
Is what I am saying correct? Is there a better way? How do other people solve it? Can you tell me why it is good/bad practice?
Thanks for all your help and advice!
Message was edited by:
BoozDetroit
> Then I encounter a problem: what if I need to show a
> list of data which come from multiple tables. The
> regular DTOs arent sufficient.
That is correct, those single table objects would not satisfy the technical requirement of displaying data from multiple tables.
> In that case I create a specialised DTO which
> contains that data for me. And maybe a specialised
> DAO for serving those specialised DTOs?
What you have done here is satisfy the technical requirement. This is fine.
The main purpose/benefit of the Data Access Object design pattern is to encapsulate data access code. The only classes in the application that should have any relational database code are the DAO classes.
If you have to hand-write SQL code and are unable to use a ORM framework such as Hibernate or CMP EJBs, then using the DAO pattern is the correct way.
Other people use Hibernate. Other people use CMP Entity EJB. Other people code JDBC code into business objects and avoid the DAO design pattern (bad practice). Using DAO when you have to hand-write SQL is good practice.
The best practice is to use the Data Access Object design pattern when you cannot use an ORM or other data persistence framework.
Using a ORM framework such as Hibernate is also a best practice, when the situation allows for it.
I agree with GhostRadioThree that you should look at using something like Hibernate. If that's not the way you want to go, then the DAO/DTO pattern set seems to be a good replacement.
> Should DAOs just fill in the id (keys) so it is up to
> the application
> using the DAOs to get the Employee class, then the
> Department class,
> and the the Location class like:
>
> Employee emp = EmployeDAO.getEmployee(1);
> Department dept =
> DepartmentDAO.getDepartment(emp.getDeptId());
> Location loc =
> LocationDAO.getLocation(dept.getLocId());
> System.out.println(emp.getEmpName() + " works in " +
> loc.getLocationName());
I would recommend you consider saving only the ID of related DTOs (foreign key references), but implement both emp.getDeptID(), which returns the ID, as well as a emp.getDept() which encapsulates the call to DepartmentDAO.getDepartment(deptID) and returns a Department object. There's no rule saying that DTO objects can't have 'helper' methods in them to do tasks like this.
You might also consider writing interfaces for all of the DTOs and making the DTOs implementations of those interfaces. This way you can easily swap out the DTOs later for other implementations, or even POJOs kicked out of something like Hibernate.
I don't have all the answers. I simply wanted to provide these ideas.
P.S. Don't forget to award Duke Stars to people that give good advice, even if it isn't me, which it most likely isn't. The new Duke Stars program is all about giving points out. You will always get more if you are low on them. 'Tis the giving season.
First of all I want to thank you all for answering. The answers you provided certainly helped me, yet I have some additional questions.
Currently the use of an ORM like Hibernate isnt possible, so I will have to stick with the DAO/DTO pattern for my needs.
The main question which remains is the following:
Imagine I have a database with several tables. I use the DAO/DTO pattern to manage the Insert Update and Delete operations per table (for instance EmployeeDAO with EmployeeDTO, DepartmentDAO with DepartmentDTO).
The DTOs are just the encapsulation of the data in their equivalent database table.
Question 1:
The reason I dont like to include a DepartmentDTO inside a EmployeeDTO is to avoid too much complexity when just managing the simple CRUD for that Employee:
IF I embed a DepartmentDTO inside a EmployeeDTO, then where do I draw the line? The DepartmentDTO can also embed a LocationDTO and so on.
I dont need those objects when I for instance just want to create a new Employee.
Is my asumption correct so far?
Question 2:
Each jsp page can contain a different View of the data in the database.
* ViewEmployees.jsp for instance can have the need for the employee name, and the department name where the employee works.
* ViewDepartments.jsp for instance can have the need for the department name and the location name of that department
* Some other jsp might combine the two above or have totally different needs.
Since my EmployeeDAO, DepartmentDAO and LocationDAO just manage the simple CRUD operations for their own simple DTO and dont link each other (they dont even know about each others existance imo), I need another mechanism to get the linked data for ViewEmployees.jsp and ViewDepartments.jsp.
In my above post I asked if making a specialised DAO/DTO is the correct way to go.
Should I make a ViewEmployeesDAO and ViewDepartmentsDAO with their corresponding ViewEmployeesDTO and ViewDepartmentsDTO?
ViewEmployeesDTO contains employee_id, employee_name, dept_id, dept_name, loc_id ?
ViewDepartmentsDTO contains dept_id, dept_name, loc_id, location_name ?
This would mean that I need to create a specialised DAO per jsp page (per specialised view on the database) with 1 or more specialised DTOs depending on what data the jsp page requires. The amount of DAOs - DTOs will increase alot.
Is that good practise? If so why? If not why not? Is there a better way to do it? My main goal is KISS (Keep It Simple Stupid) and transparency to make application updates-expansions-maintenance as easy as possible without having to resort to ugly code/hacks to make it work.
Thank you for your time, for reading my post and letting me learn from your experience. Ofcourse I will award Duke Stars, I ll raise them to the maximum amount allowed per thread!
Message was edited by:
BoozDetroit
Message was edited by:
BoozDetroit
> Imagine I have a database with several tables. I use
> the DAO/DTO pattern to manage the Insert Update and
> Delete operations per table (for instance EmployeeDAO
> with EmployeeDTO, DepartmentDAO with DepartmentDTO).
> The DTOs are just the encapsulation of the data in
> their equivalent database table.
>
> Question 1:
> The reason I dont like to include a DepartmentDTO
> inside a EmployeeDTO is to avoid too much complexity
> when just managing the simple CRUD for that
> Employee:
> IF I embed a DepartmentDTO inside a EmployeeDTO, then
> where do I draw the line? The DepartmentDTO can also
> embed a LocationDTO and so on.
> I dont need those objects when I for instance just
> want to create a new Employee.
I think you should revisit the idea of having a DepartmentDTO inside an EmployeeDTO. Doing this would allow you to create the 'specialized' DAOs you mention in the second question. Also, it allows you to do cascading operations. If you persist a new EmployeeDTO and the DepartmentDTO is non-null, you can automatically persist the DepartmentDTO.
While you say you can't curently use an ORM technology, I think you should still try to mirror there features as much as possible in your DAO/DTO code trees. All of them that know about would put a getDepartment() inside the Employee class.
> Question 2:
> Each jsp page can contain a different View of
> the data in the database.
> * ViewEmployees.jsp for instance can have the need
> for the employee name, and the department name where
> the employee works.
> * ViewDepartments.jsp for instance can have the need
> for the department name and the location name of that
> department
> * Some other jsp might combine the two above or have
> totally different needs.
>
> Since my EmployeeDAO, DepartmentDAO and LocationDAO
> just manage the simple CRUD operations for their own
> simple DTO and dont link each other (they dont even
> know about each others existance imo), I need another
> mechanism to get the linked data for
> ViewEmployees.jsp and ViewDepartments.jsp.
>
> In my above post I asked if making a specialised
> DAO/DTO is the correct way to go.
> Should I make a ViewEmployeesDAO and
> ViewDepartmentsDAO with their corresponding
> ViewEmployeesDTO and ViewDepartmentsDTO?
> ViewEmployeesDTO contains employee_id, employee_name,
> dept_id, dept_name, loc_id ?
> ViewDepartmentsDTO contains dept_id, dept_name,
> loc_id, location_name ?
>
> This would mean that I need to create a specialised
> DAO per jsp page (per specialised view on the
> database) with 1 or more specialised DTOs depending
> on what data the jsp page requires. The amount of
> DAOs - DTOs will increase alot.
> Is that good practise? If so why? If not why not?
> Is there a better way to do it? My main goal is KISS
> (Keep It Simple Stupid) and transparency to make
> application updates-expansions-maintenance as easy as
> possible without having to resort to ugly code/hacks
> to make it work.
You would probably find that you end up making a 'specialized' DAO for each foreign key association that your DB schema has. In the end, I think this would create a more complex, less manageable code tree than the way I encouraged above.
I'm not trying to say the way you are describing won't work. I just think you might want to seriously consider what I outlined here.
You really need two types of DTOs, a standard DTO, and a DetailDTO.
The problem with putting the DepartmentDTO in the EmployeeDTO is exactly as you described, where do you draw the line?
A simple DTO should never really contain other DTOs. But you can supply a detail DTO instead that can contain simple DTOs. You would typically have a detail DTO assembler class that would gather all of the required simple DTO's to construct the detail DTO.
That way, whenever you just want employee info, just get the simple DTO directly from the DAO, but if you need more info, like the department information, then get the detail DTO from the assembler.
This might explain it a little better:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObjectAssembler.html
I don't really agree with this. I think your DTOs should create an object tree that pretty much mirrors your DB tables, exactly as the objects created by ORM technologies do. This isn't a bulky solution. Remember, you don't really have a DepartmentDTO inside the EmployeeDTO. You just have a reference. And, if you write the code correctly, that reference can remain null until the first call to getDepartment() is made. Lazy initialization of these references will keep the object tree as slim as possible.
Also, you can pretty much ignore daFei. I've been told, by numerous sources in these forums, that he's a troll. alphamale is worth ignoring as well, if you ever run into him.
Thank you for all your replies!
Chekote makes a strong point with the TransferObjectAssembler pattern, which describes just what I was trying to explain in this thread.
codebook also makes a strong point with the lazy loading argument, which solves the bloated problem.
Yet in my specific application (webbased) I use a MVC pattern to separate database access logic, bussiness logic and presentation logic from each other.
In the View I only work with DTOs that encapsulate data received from the other tiers. Lazy loading of extra DTOs requires access to the database, which isnt permitted in the View.
Unless I am missing something I think the TransferObjectAssembler described by Chekote provides the correct solution.
Question 1:
What do you think of my analysis as described above in this post? Am I missing something or is it correct?
Question 2:
I can see very clearly where codebook 's lazy loading is the better solution: in a gui application, since I dont work with the MVC pattern there.
From this I draw the conclusion that the application determines what patterns are best used, that no patterns are right or wrong, but that the situation determines what solution is better.
Is this conclusion correct? What is your vision about patterns?
Thanks for helping me!
> Thank you for all your replies!
You are more than welcome. That's what these forums are for. They're no good if nobody ever replies. I'm just trying to do my part.
> From this I draw the conclusion that the application
> determines what patterns are best used, that no
> patterns are right or wrong, but that the situation
> determines what solution is better.
>
> Is this conclusion correct? What is your vision about
> patterns?
>
Absolutely! No single pattern should ever be viewed as a perfect solution for all situations. The problem is that many people, including myself, only know a small handful of patterns really well. So as they say, if all I have is a hammer, everything else looks like a nail. The thing you have to do is continually learn more patterns. Eventually we'll realize that not everything is a nail. Every once in a while we'll find a screw and use a screwdriver instead of the hammer.
> Thanks for helping me!
Again, your welcome.
P.S. Don't forget to reward some of those Duke Dollars to the folks that helped out, even if they don't go to me.
Thanks for all the replies! Duke Dollars have been awarded to all posters!
> I don't really agree with this. I think your DTOs
> should create an object tree that pretty much mirrors
> your DB tables, exactly as the objects created by ORM
> technologies do.
It should mirror the data model. The data model will often but not always produce a one to one mapping with tables. It is less likely to do so when the object model must represent logical entities from different sources.
How do you think the Transfer Object Assembler pattern scales? That is, say I have 100,000 composite transfer objects that I need to assemble - is there a better way than doing a lookup on each separate entity to assemble the composite object? If there were 3 data objects in the composite that my mean 300,000 individual queries. I guess you could just use a query joining the tables to assemble the object, but that is not what the pattern is showing.
