DAO/DTO Help

Discussions

General J2EE: DAO/DTO Help

  1. DAO/DTO Help (2 messages)

    Where do your DAO/DTO implementations draw the line?


    Simple DTO and DAO (one per table) I get, but what about more advanced DAOs?

    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... Taking another approach to the same question...Say I have an employee_type table having values of fulltime, parttime, etc. Whay do you store in the employee class now? Just a String with the value of the type or the key to the employee_type table? Is it application dependent?

    Any thoughts, links, tips, best practices, whatever would be helpful!

    Thanks!

    Matt

    Threaded Messages (2)

  2. DAO/DTO Help[ Go to top ]

    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. Instanatiate 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 wo'nt 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?

    4. Something else...

    Thanks!

    Matt
  3. DAO/DTO Help[ Go to top ]

    Where do your DAO/DTO implementations draw the line?Simple DTO and DAO (one per table) I get, but what about more advanced DAOs? 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 thispublic 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());orEmployee 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... Taking another approach to the same question...Say I have an employee_type table having values of fulltime, parttime, etc. Whay do you store in the employee class now? Just a String with the value of the type or the key to the employee_type table? Is it application dependent?Any thoughts, links, tips, best practices, whatever would be helpful!Thanks!Matt
    These are excellent questions. These are the kinds of questions that don't get asked often enough. More developers should be concerned about good OO like you are. As you know there are no right or wrong answers. It just depends on the situation.

    In your example of Employee and Department, I usually would have a a Department object within the Employee. Mostly because it makes the code easy to understand and manipulate. Employee.getDepartment();

    However, if I were to go this route, I would want to instanciate all of the Departments first because the Department is the parent object of Employee. There would be some sort of Department collection and when I create a new Employee object I get a reference to the existing Department from the list. That way each two Employees from the same Department would refer to the same instance of Department.

    Or maybe that's a stupid idea. :) I guess it depends on how many Departments there are.

    What do you think?