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 ?
>

FWIW, having all Database specific code together in one place seems more managable than having it sprinkled through the application(s).

>
> (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.
>

It also opens up a bit more "design space" allowing you to think about actually isolating business logic perhaps? The application developers use these Objects which happen to encapsulate all of the gritty details of db's.

>
> 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 ?
> How often JDBC API is likely to change ? Will the change be such that
> it's not backward compatible ?

But will your design be "Forward Compatible?"

>
> Just trying to find what's the best approach for a new Java project. Any
> help ?

Do it now or redo it later.

Good luck

johng Received on Tue Nov 09 1999 - 17:23:59 CST