With respect to Connection Strings, I responded to one of your other posts
(lemme see if I can find it) with how to address that. The
DBConnectionStringBuilder implementations will handle this though.
With respect to JDBC though, (I admit, it's been 4 years since I used it),
how does it handle named parameterization when the underlying db doesn't?
The fact that you set parameters differently for different providers isn't
really ADO.NET's fault though. Different vendors implement their providers
differently, but even if they wanted to, Microsoft would have a hard time
forcing people to implement them in a standard way across the board. if I
were to build BillsOracleClient b/c I didn't like the OracleClient
implementation, what I'd need to do is work with the interfaces and base
classes. However I could implement those interfaces however I pleased. If
Oracle or Microsoft told me "We don't like the way you did that", I'd be
free to tell them to go fly a kite. It's my provider I can implement it how
I want. Now let's say that you did the same for a DB2 Client and chose
something that was specifically much different from mine. Microsoft could
call us up and say "Hey you guys, we're trying to keep things consistent so
we want you to change it so people can use the same param constructors for
each of your providers" but we'd be free to say no. Without changing the
architecture in a serious way, there's not much they can do to force people
to implement the interfaces a certain way, nor do i think it would all that
well recieved if they did. Moreoever, by giving you the interfaces, the
world is your with respect to creating providers. The downside is that you
don't have cross -db compatibility in a true sense, but you don't anyway in
most cases b/c you want to take advantage of db specific features. So if
you wanted to use += for a join, you wouldn't be able to use it for all of
the following, Oracle, Sql Server and Access. Well, Joins are a pretty
fundamental staple and the syntactical differences would stop you. same for
many functions, ISDATE doesn't produce the same results in both Sql Server
and Access. There's no DUAL in Sql Server or Access. There are many more
similar issues that stop you from having true agnostic DB access and these
are much more serious than the parameter issue. If you can't use the same
syntax because of the back ends, then the rest is more or less academic. To
be honest, I really can't see this changing in any version and I don't see
much desire to even move in that direction. Now more than ever Sql Server
and Oracle both have a ton of specific features that others don't have. To
take advantage of them you need to use a specific library. And in most
cases, the opportunity costs associated with not using these features far
outweigh the benefit is being able to use the same syntax for both. I can't
speak for Microsoft but I think these differences are going to widen more
than get smaller.
