When it comes to app architecture, I always recommend the Core J2EE Patterns book. The Second Edition is now available and you can get an overview of it at http://corej2eepatterns.com/Patterns2ndEd/BusinessObject.htm
In response to your question: A DAO should only contain the SQL code for the create/read/update/delete/find methods of one single database file or view. The Business Object, which is new in the Second Edition, wraps the DAO and manages the state and business rules for that one object. Remove any business rules, etc currently in your DAO and move them to the associated Business Object when refactoring. The Application Service, which is also new in the Second Edition, manages business rules across multiple objects (Business Objects and/or DAOs). Remove any business rules, etc currently in your Session Façades and move them to the Application Service when refactoring. Leave the transaction control, database connection stuff, etc in the Session Façade. So, go with your first example. Employee and Department should each have their own DAO. If Department is just a simple lookup table, you could combine them at the Business Object level. If Department is complicated with its own set of business rules, then make use of an Application Service. Wiebe de Jong -----Original Message----- From: Matthew J. Vincent [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 8:21 AM To: Struts Users Mailing List Subject: [OT] DAO ... where to draw the line? [OFF TOPIC] I know this is a struts forum, but as struts developers using DAOs, where do your DAO 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... Any thoughts, links, tips, best practices, whatvere would be helpful! Thanks! Matt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
