• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DAOs and complex/aggregated objects

 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your response. What you said has made sense so I will rewrite my DAOs accordingly.

Happy New Year,

Ed
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic