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