This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes JDBC and the fly likes Portable code 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 "Portable code" Watch "Portable code" New topic
Author

Portable code

Paul Medford
Ranch Hand

Joined: Aug 28, 2001
Posts: 33
Hi all:
Well, JDBC is great to connect to any database that has a JDBC driver. Changing databases is made easy by changing the driver - we know that.
But, considering that not all databases support auto-increment for primary keys, or they don't all support all possible joints, or whatever... How do you implement your code to make it portable across several databases?
1) First, do you save your SQL statements somewhere in a config file (or XML)?
2) Do you implement your business logic that returns a recordset in a separate class for each database you plan to support, so that switching to a different database is just a matter of implementing a new class without changing the code in your app?
3) Is it where the DAO design pattern comes in?
I was facing that problem when I was developing an app that connected at first to MS Access, then I switched to MySQL (or was it another one? don't remember) that did not support auto-increment. I had to recode my app.
Any thought?
Thanks,
Francois
Adam Hardy
Ranch Hand

Joined: Oct 09, 2001
Posts: 566
in n-tier theory, you have a seperate tier for database access which you would code for a particular target database. to use the app with another database, you would code another database access layer. you shouldn't have any SQL outside the database or database access layer.
You would have to decide on a strategy for passing the data from the data services layer up to the business layer - either xml, or CachecRowSets or UDTs or whatever.
What's DAO? Surely you don't mean the MS Data Access Objects?

I have seen things you people would not believe, attack ships on fire off the shoulder of Orion, c-beams sparkling in the dark near the Tennhauser Gate. All these moments will be lost in time, like tears in the rain.
Paul Medford
Ranch Hand

Joined: Aug 28, 2001
Posts: 33
DAO is in fact Data Access Object. But it is not the MS Access DAO, it is a design pattern.
http://java.sun.com/j2ee/blueprints/design_patterns/data_access_object/index.html
Reading through the specs I think that DAO is what is used to decouple the Business Logic from the Data Access Logic that I was talking about.
Well, thanks,
Francois
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Portable code