You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Matthew J. Vincent" <vi...@cs.usm.maine.edu> on 2004/08/11 17:21:23 UTC
[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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: [OT] DAO ... where to draw the line?
Posted by Robert Taylor <rt...@mulework.com>.
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:vincent@cs.usm.maine.edu]
> 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:vincent@cs.usm.maine.edu] 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DAO ... where to draw the line?
Posted by "Matthew J. Vincent" <vi...@cs.usm.maine.edu>.
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:vincent@cs.usm.maine.edu] 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DAO ... where to draw the line?
Posted by "Matthew J. Vincent" <vi...@cs.usm.maine.edu>.
<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:vincent@cs.usm.maine.edu] 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: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>> .
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DAO ... where to draw the line?
Posted by Rick Reumann <st...@reumann.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DAO ... where to draw the line?
Posted by "Matthew J. Vincent" <vi...@cs.usm.maine.edu>.
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:vincent@cs.usm.maine.edu] 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>> .
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DAO ... where to draw the line?
Posted by Navjot Singh <na...@net4india.net>.
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:vincent@cs.usm.maine.edu]
>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: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: [OT] DAO ... where to draw the line?
Posted by Wiebe de Jong <wi...@shaw.ca>.
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:vincent@cs.usm.maine.edu]
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org