aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes DAOs and complex/aggregated objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "DAOs and complex/aggregated objects" Watch "DAOs and complex/aggregated objects" New topic
Author

DAOs and complex/aggregated objects

Edward Winchester
Ranch Hand

Joined: Sep 16, 2009
Posts: 65
Hello,

In my application I have an object called a job. This job is composed of some attributes at its own level and a list of smaller objects (for the sake of this posting, let's call them joblets). A joblet has a list of related files and other attributes too. This information is stored in a relational database. e.g.



What' I'm trying to get across is that there's a hierarchy. Additionally, although a job is composed of its joblets, a joblet can also be thought of by itself and could be manipulated in isolation within the application.

I've been creating DAOs for the above and have JobDAO, JobletDAO, FileStoreDAO, FileFormatDAO - essentially one DAO per table.

What follows is the interface code to the DAOs to illustrate the design issue I'm now facing:



Because JobDAO is mainly responsible for the JOB table, the implementation of findAllJobsForUser() method simply returns the JOB-level information so the Job object doesn't contain any joblets. The calling code would then need to invoke findAllJobsletsForJob() method to populate the Job object.

I like this approach because the DAOs are just one per table and easy to comprehend. Another thing I like is that DAOs don't need to know about each other. I dislike this approach because the caller (in my case the service layer) has quite a bit of complexity to return a fully-constructed Job object.

Is this a common design issue for Java EE developers to face, and what's the best design to go with?

Thanks,

Ed
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
I like this approach because the DAOs are just one per table and easy to comprehend. Another thing I like is that DAOs don't need to know about each other. I dislike this approach because the caller (in my case the service layer) has quite a bit of complexity to return a fully-constructed Job object.


One DAO object for only one table is a rudimentary design. If it introduces a high-level of complexity to get a Job object, then then your DAO implementation is not helping. A better design would be to have a single DAO object with the functionality of getting a collection of Job objects based on some critieria, a single Job object and anything else needed by the business objects, e.g. Joblets. This is easier to understand and to code, and will perform better if in a distributed environment.

A DAO API should be more friendly to client objects rather than the relational tables.

A "simple" DAO API which introduces complex data access code is not a good thing.

Ideally, most of your SQL logic for joining data should be encapsulated in stored procedures and the DAO should simply be calling these procedures with parameter values.




Edward Winchester
Ranch Hand

Joined: Sep 16, 2009
Posts: 65
Thank you for your response. What you said has made sense so I will rewrite my DAOs accordingly.

Happy New Year,

Ed
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: DAOs and complex/aggregated objects