Re: [OT] DAO ... where to draw the line?
LAST bump. I promise!
Thanks!
Hi all,
Thanks for the info. Here's another issue.
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 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... Another pattern, etc?
Thanks!
Matt
Navjot Singh wrote:
hi matthew,
I wont say that you go with one or other of your approaches.
It depends upon type of assosciation that 2 entities may share. They
may have aggregation or composition relationship. Depending on that
your DAO implementation will decide that you need to get ONLY id or
the composite objects.
Let me explain.
Say you have class named ORDER ad ORDER_DETAILS. (consists-of
relationship) Order without order details is nothing. So you may get
the OrderDetails object as well when you get Order.
Now say you have EMPLOYEE and DEPARTMENT. (has-a relationship)
EMPLOYEE *may* still exists with or without department. So you may
get only id of department and later fetch the department.
Think in employee table, you have relationship (reports-to). If you
specify this relation as composition, you may go on fetching the
objects all the way up to the organization chart ;-)
Do i make sense?
Navjot Singh
-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]
RE: [OT] DAO ... where to draw the line?
Strategy 3.
I would basically have a DAO that handles the search query
and returns a collection of value objects for the related use case.
When the user clicks on a specific employee, then render the
details using your employee DTO.
As far as patterns are concerned you may want to take a look
as the ValueObjectAssembler pattern or the TransferObjectFactory
patterns.
hth,
robert
-Original Message-
From: Matthew J. Vincent [mailto:[EMAIL PROTECTED]
Sent: Monday, August 16, 2004 10:09 AM
To: Struts Users Mailing List
Subject: Re: [OT] DAO ... where to draw the line?
LAST bump. I promise!
Thanks!
Hi all,
Thanks for the info. Here's another issue.
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 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... Another pattern, etc?
Thanks!
Matt
Navjot Singh wrote:
hi matthew,
I wont say that you go with one or other of your approaches.
It depends upon type of assosciation that 2 entities may share. They
may have aggregation or composition relationship. Depending on that
your DAO implementation will decide that you need to get ONLY id or
the composite objects.
Let me explain.
Say you have class named ORDER ad ORDER_DETAILS. (consists-of
relationship) Order without order details is nothing. So you may get
the OrderDetails object as well when you get Order.
Now say you have EMPLOYEE and DEPARTMENT. (has-a relationship)
EMPLOYEE *may* still exists with or without department. So you may
get only id of department and later fetch the department.
Think in employee table, you have relationship (reports-to). If you
specify this relation as composition, you may go on fetching the
objects all the way up to the organization chart ;-)
Do i make sense?
Navjot Singh
-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]
Re: [OT] DAO ... where to draw the line?
Matthew J. Vincent wrote: Hi all, Thanks for the info. Here's another issue. 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 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... I wouldn't make new DTOs/Value Objects. I'd just do number 1 above: Instanatiate an Employee object and only fill in the relative information? OR sometimes 2 is ok if it's not a big query, that way could reuse your query. BUT, you also mention that are doing this based on a search, often for that what you search on won't necessarily even be in the EmployeeDTO so I often DO make a SearchDTO to pass to my service layer. For example maybe you want to search on employees who have been hired before a certain date and after a date. You then would have a startDate and endDate in your searchDTO. I susually always end up with a searchDTO for when I need to capture criteria to search on. But if say for displaying a list of Employees that the user can pickf from.. I'd simply reuse the basic Employee object, even if it's only populated with a name and ID. By the way, I recommend you look at iBATIS for this stuff. It really makes this stuff pretty easy http://www.ibatis.com/. I even have a small example lesson showing it in use (although it needs to be updated) http://www.reumann.net/do/struts/ibatisLesson1 -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DAO ... where to draw the line?
Hi all,
Thanks for the info. Here's another issue.
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 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!
Matt
Navjot Singh wrote:
hi matthew,
I wont say that you go with one or other of your approaches.
It depends upon type of assosciation that 2 entities may share. They
may have aggregation or composition relationship. Depending on that
your DAO implementation will decide that you need to get ONLY id or
the composite objects.
Let me explain.
Say you have class named ORDER ad ORDER_DETAILS. (consists-of
relationship) Order without order details is nothing. So you may get
the OrderDetails object as well when you get Order.
Now say you have EMPLOYEE and DEPARTMENT. (has-a relationship)
EMPLOYEE *may* still exists with or without department. So you may get
only id of department and later fetch the department.
Think in employee table, you have relationship (reports-to). If you
specify this relation as composition, you may go on fetching the
objects all the way up to the organization chart ;-)
Do i make sense?
Navjot Singh
-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]
.
-
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]
Re: [OT] DAO ... where to draw the line?
bump
Matthew J. Vincent wrote:
Hi all,
Thanks for the info. Here's another issue.
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 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!
Matt
Navjot Singh wrote:
hi matthew,
I wont say that you go with one or other of your approaches.
It depends upon type of assosciation that 2 entities may share. They
may have aggregation or composition relationship. Depending on that
your DAO implementation will decide that you need to get ONLY id or
the composite objects.
Let me explain.
Say you have class named ORDER ad ORDER_DETAILS. (consists-of
relationship) Order without order details is nothing. So you may get
the OrderDetails object as well when you get Order.
Now say you have EMPLOYEE and DEPARTMENT. (has-a relationship)
EMPLOYEE *may* still exists with or without department. So you may
get only id of department and later fetch the department.
Think in employee table, you have relationship (reports-to). If you
specify this relation as composition, you may go on fetching the
objects all the way up to the organization chart ;-)
Do i make sense?
Navjot Singh
-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]
.
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[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]
RE: [OT] DAO ... where to draw the line?
-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?
Typically, I try to keep things as modular as possible. This typically means that if
I'm using JDBC, as opposed to Hibernate, I put the object graph together in the
business layer, rather then try and do it in the DAO layer. This allows me some
flexibility in what I return back. I can have a business method that will only return
the employee, as opposed to the entire graph if my view only needs to see the employee
and the entire graph might prohibitive ( time/space) to fully extract.
If you put everything into the DAO it can be somewhat more troublesome to do, possible
certainly, but it always seems to me that how much data you pull back is a business
requirement related to the server power (memory/speed) you have, not a function of the
data itself.
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]
RE: [OT] DAO ... where to draw the line?
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]
