I think the backward compatibility thing with JDBC has been blown twice
already.
(2)Not only insulates you from JDBC code churn
(DB changes have no effect thanks to JDBC) but gives you a layer of OO
that JDBC just doesn't have. I find that it's more of a spec than a class.
It's just a collection of fucntions, excuse me, methods that have to be in a
class because Java dictates it.
Sameer Utrankar <sameeru_at_exchange.ml.com> wrote in message
news:3828444F.CA19CD8C_at_exchange.ml.com...
> 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.
>
> 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 ?
>
> Just trying to find what's the best approach for a new Java project. Any
> help ?
>
>
>
Received on Tue Nov 09 1999 - 11:57:52 CST
