aspose file tools*
The moose likes JDBC and the fly likes DAO pattern and server's DataSource approach Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "DAO pattern and server Watch "DAO pattern and server New topic
Author

DAO pattern and server's DataSource approach

steve francisco
Ranch Hand

Joined: Jan 26, 2005
Posts: 46
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
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
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
internet detective
Marshal

Joined: May 26, 2003
Posts: 30352
    
150

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


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
steve francisco
Ranch Hand

Joined: Jan 26, 2005
Posts: 46
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
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
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
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
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
internet detective
Marshal

Joined: May 26, 2003
Posts: 30352
    
150

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
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
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
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
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.
     
     
    subject: DAO pattern and server's DataSource approach