How to use Data Access Objects for serialized & relational database data access

Question

Hi all,

I am developing a C++ domain model class library which should provide some facilities or a framework (i.e. interface classes etc) for writing/reading class instance data to/from both a binary file and a RDBMS. The basis for this library is an application that uses a RDBMS, and there are several methods which instantiate a class by performing a sequence of database retrieve and update calls to fetch collections of member data. The serialized data access has a different way of organizing its data, so I want the domain model to be completely ignorant of primary/foreign keys, IDs etc.

To solve this problem, I consider using the Data Access Object (DAO) pattern, and would like to have some advice on the 'granularity', lifetime and use of DAO objects (in your replies, please note that I'll be using C++, not Java, and that the domain class cannot hold any ID/key info from the RDBMS or binary file store):

1. Does each Foo instance of a domain object have its own FooDAO instance, or is there a single FooDAO instance for all instances of class Foo?
2. Is the FooDAO created once for each Foo instance, or would the FooDAO instance be created only when access to data is needed, and destroyed immediately afterwards?
3. The J2EE page on DAO introduces a DTO in addition to the DAO. Why can't the DAO transfer the data?
4. For a complex domain class Foo that has instances of other domain classes Bar, it seems inevitable that the FooDAO class uses the BarDAO class to retrieve data. This would lead to parallel hierarchies/dependencies in the domain class structure and the DAO class structure. How can this be managed best?

Thanks for your help!

Answer 1

I don't have a good solution for you, but I can tell you what I have, and some thoughts and experiences. I have built something very similar, based on a model I had seen used before, as a C++ library.

Some thoughts, in no particular order:

• Have a separate instance of the DAO object for each instance in the DB. If you have a shared instance, thread synchronization may be a problem, and you'll be forced into doing a lot of copies.
• My library DAO classes use types closely associated with the RDBMS types, for a couple of reasons. First, the library supports automatic creation and update of storage in the underlying data store, so the classes need to have enough information to create the tables. Second, it makes data transition much easier, and optimizable (you can do direct ODBC/OLEDB data copies using the native interfaces, for example). The downside is that you can't have "nice" class types in the DAO objects (eg: string abstractions with more data than the actual string buffer).
• I create on demand, certainly, because there's potentially much more data in the store than would be practical to put in memory.
• I try to keep the DAO classes simple, with minimal accessor functionality, and "close" to the underlying data structures. That means no inheritance from other DAO classes, instances have key variable members, etc.

On top of the DAO classes I build more accessible classes which represent the data in my application, and may or may not map 1-1 to a DAO class. These are allowed to have any type of members and structure, are supposed to be what the app uses, and have methods to copy data to/from the DAO classes which underlie them.

Hope that helps.

Answer 2

I don't know the best implementation, but here's what I've seen done:

1. Separate for each instance.
2. Created right before it is needed and destroyed right after.
3. Don't know.
4. Combine the data outside of the DAO instances, thereby avoiding the coupling.

Disclaimer: This is just what I've seen done.