DAO pattern and server's DataSource approach

[steve francisco]

As we know, DAO is a common pattern that allows java code to access various backend databases. Every application server allows applications to use "datasource" so that the server can build up database connection for you. I am wondering --

If my application is an EJB or web component application running in an application server, then I can create different datasource for different backend databases, then why do I need DAO pattern ? It seems the only reason I will use DAO is when I write database connection stuff by myself. Is that right ?

[Adeel Ansari]

I think you didn't get DAO really. Here is a brief but somewhat complete definition.

Data Access Object

Most Web applications use a persistent storage mechanism to store data. The data access methods may differ for different types of data sources, which might range from relational databases to legacy systems. Even within an RDBMS environment, the actual syntax and format of the SQL statements may vary depending on the particular database product. Also, there might be applications that use more than one data source.

The coupling between the business tier and the database tier can cause difficulties in migrating the application from one data source to another. When this happens, all the business components that access the data source need to be altered accordingly. To overcome these dependencies, the business tier can interact with data sources through a Data Access Object (DAO).
The DAO implements the access mechanism required to work with the data source.

The business component that relies on the DAO uses the simpler and uniform interface exposed by the DAO for its clients. By acting as an adapter between the component and the data source, the DAO enables isolation of the business components from the data source type, data access method, and connectivity details. Thus the data access logic is uniform and centralized, and database dependencies are minimized by the use of this pattern.

[Jeanne Boyarsky]

Adeel,
Where is that from? Book? Website? Former post?

[steve francisco]

thanks Adeel, let's think about a concrete scenario: Suppose my backend database need to be either Oracle or SQL server, I can create two different datasource on my application server (one for oracle and one for SQL server). DO you mean I still should use a DAO between my component and these two datasource ? In other words, server's datasource eliminates my coding of jdbc connection kind stuff but it doesn't replace the function of DAO, is that right ?

thanks

[Adeel Ansari]

 

Originally posted by Jeanne Boyarsky:
Adeel,
Where is that from? Book? Website? Former post?

Hmmm. Did you like it?
its from IBM DeveloperWorks.
cheers.

[Adeel Ansari]

Steve,

If both databases are same, just a vendor difference, one is Oracle and other is SOL Server then you can use the same DAO for both. But keep in mind some vendor specific sql code might not work. ANSI should work for both. And if you can implement something like CMP entity beans or someother mapping tool, then it could be database independent.

cheers.

[Jeanne Boyarsky]

 

Originally posted by Adeel Ansari:


Hmmm. Did you like it?
its from IBM DeveloperWorks.
cheers.

As a matter of fact, yes I did For the future, it's good to provide links when cutting/pasting from an outside source.

[Adeel Ansari]

 

Originally posted by Jeanne Boyarsky:

As a matter of fact, yes I did For the future, it's good to provide links when cutting/pasting from an outside source.

Ok madam, so this was the main reason of your asking .
But actuality is i totally forgot to mention.

Thanks for your reminder, Jeanne.

[David Harkness]

While RDBMS independence is a good thing, almost every project on which I have worked has stuck with the same single database vendor (and often version). To me, even more important is that the DAO provides an abstraction layer between your application business logic and SQL. Your business logic shouldn't be performing select and insert operations; rather it should be making method calls like these:

findUsersByFirstName(firstName) -> List

deleteDevice(name) -> boolean

findAddress(id) -> Address

Abstracting the API like this allows you to even change from JDBC to something entirely different or only somewhat related: Hibernate, entity beans (shudder), XML, an OODB, flat files, your cousin Bob's long term memory, whatever. If you only allow the DataSource to be swapped out, you have very limited options without rewriting a lot of application code.