wood burning stoves 2.0*
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 Murach's Java Servlets and JSP this week in the Servlets 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: 565
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
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Portable code
 
Similar Threads
DriverManager lookup
MSAccess slow?
interface problem - !@#$%^&*
Help on Sybase
Java Class Implementation Logic