DAO Design Pattern

[Jeff Storey]

I've been reading up on the DAO design pattern, and I'm still a little unclear on a few points. Let's assume I'm working with a simple banking application that has Customers and Accounts. I understand that I'd have interfaces that were CustomerDAO and AccountDAO (or something similar), but my real question is about the implementations.

Would I have two separate implements of each if I was connecting to two separate types of databases, such as MS Access and MS SQL? It seems like the only thing that would really be different is the connection string for the database. If I could use one DAO implementation there, in what instance would I need another type of implementation (assuming I always have a database backend and not storing things in a flat file). Seems like all databases would handle SQL pretty much the same and I shouldn't need different DAO implementations.

Thanks,
Jeff

[Stan James]

The guys around me just migrated a bunch of SQL Server code to UDB. They got bit by a number of small syntax differences and had to change code. I think you can very carefully code to a common subset to avoid that kind of thing. They were able to manage the differences in the drivers and connection strings through configuration without a class per database vendor.

[Adeel Ansari]

As Stan already said, that its better to use a standard SQL and say not a vendor specific stuff if its likely that your underlying database tends to change in future. Furthermore, I would like to add that its a common practice to make a utility class for database connections and not write any connection related code in your DAOs. Hence, your DAOs would be independent of underlying database, assuming you haven't used any vendor specific SQL in there. You only need to change the code in your database connection utility class not any of your DAOs. Better use a property file or similar things to define your connection string, this way possibly you don't even need to change your connection utility class.

[Jeff Storey]

Thanks for the responses. What you are saying makes perfect sense. My question now becomes - when would I need another implementation of a DAO? If all I use is standard SQL, why would I ever need multiple CustomerDAO implementations (unless of course I changed to a completely different type of persistent storage that was not a database, but let's assume that is not the case).

Thanks,
Jeff

[Adeel Ansari]

Couldn't think of any other.

May be in a distributed environment where we have multiple versions of Java Runtime.

[Peer Reynders]

How about "real" DAOs vs "mock" DAOs (for automated unit testing)?

If you want to save even more work then go for GenericDAOs.

Don't repeat the DAO!

Generic Data Access Objects

However I haven't seen a convincing argument yet why one would retain DAO's once you commit to utilize an ORM. Once you've gone that far you might as well move to repositories.
[ August 07, 2007: Message edited by: Peer Reynders ]

[Adeel Ansari]

Originally posted by Peer Reynders:
How about "real" DAOs vs "mock" DAOs (for automated unit testing)?

We are using the same DAOs with easymock.