Re: JDBC Class Abstraction

Sameer Utrankar wrote:
>
> This is a design related question and not really a programming issue.
>
> Is it good to:
> (1) Use JDBC directly in the application ?
> (2) Build a DBAccess layer on top of JDBC and ask programmers to use
> the layer ?
>
> (1) gives you quicker solution because no extra effort of layer
> building, need for programmers to know JDBC, Lot of work if JDBC API
> changes and app needs to be changed.
> (2) upfront effort to build the layer and easy to switch (?) if JDBC API
> changes down the road.
>

Dear Sameer,

My two cents: In general, some set of classes that isolate JDBC-specific code is a good idea. However, within such a layer, you may wish to have an abstraction that enables you to communicate back to and receive information from the application.

As you learn more about OOA/OOD methods, (Refactoring for instance) I think you'll find that reuse is quite valuable and can be quite applicable to JDBC.  

> I know Object Oriented Pundits will prefer to chose (2) and argue such
> as what if database changes from Oracle to Sybase, JDBC API changes etc.
> But taking a practical view how often such things happen in a company ?

SQL is not all that much more of a standard than COBOL was. Although JDBC helps, there are important database capabilities which are quite different for various manufacturers (Oracle, Sybase, Informix, etc). As a consequence, unless you macro-code your SQL in some way, it probably won't be backward compatible when you convert from one database to another.

> How often JDBC API is likely to change ? Will the change be such that
> it's not backward compatible ?

Looking into my crystal ball, I'd say take a look at the JDBC 2.1 Spec proposal that is now in review. Very quietly, JDBC is trying to switch from RDBMS support (SQL92) to ORDBMS (SQL99). Take a close look at Appendix D.

For a brief overview of JDBC 2.1 and objects see:

    home.earthlink.net/~richkatz/news.html

HTH, Rich Katz Received on Sun Nov 14 1999 - 20:58:28 CST