Is ADO.NET Microsoft's answer to JDO ?

  • Thread starter Thread starter Nico
  • Start date Start date
N

Nico

I have some experience in ADO.NET and none in JDO. The articles on JDO
(Java Data Objects - I think) though, seem to suggest that it is a new and
the 'best yet' attempt at solving the relational-object mismatch. From what
I understand, as developer I would really only work with JDO's and link any
sort of backend datastore (Relational, object database, files, XML files and
database etc) to the JDO and truly code against and object model. The JDO's
handle caching, transactions (or makes it very easy for me to manage),
instantiating new instances while sorting out id's an various optimizations.

I got on this track through an article by Dirk Bartels on DevX 'JDO Brings
DB Programming into 21st Century Despite Controversy'
(http://www.devx.com/devx/editorial/16373)

It all sounds great.

In ADO.NET a still work with tables and relations like in a relational
model.
Strongly typed datasets, and similar commercial attempts such as Deklarit,
is actually just mass code generation on an inherantly relational model, and
in my view a weak solution for a very big problem.

So is ADO.NET Microsoft's answer to JDO ? If not, what is ?
 
I don't know that this is an apples to apples comparison
per se. ADO.NET is more of a framework for dealing with
data than a specific mechanism itself. The fact that a
DataAdapter doesn't need to know about the tables it
fills, and data tables don't care how they came to be is
testimony to how disconnected (and IMHO Cool ADO.NET is).
I'm not an expert on JDO although I am familiar with it,
and it doesn't seem that it's intended usage is the same.
For instance, it is not uncommon to use Datatables as high
level temporary storage objects taht never come from or go
to a Database. I don't see an analogy in JDO.

IMHO, there's a lot of hype with every technology, some
more than others. In most industries, health care for
instance, the old days were dominated by large proprietary
vendors. There's a trend driven by market forces to get
away from this approach and it's happening slowly but
surely. However, using my Health Care example, you have a
bunch of vendors, some of which have 14000 fields in their
system, others that have say 10000. There's a huge
disparity. I can use XML to map certain fields over, but
what about the ones that don't exist? Health Care's
solution was to agree on a standard for data formatting,
namely HL7. This standard, and only this standard, allows
vendors and trading partners to play nice together and
communicate transparently provided they implement the spec
correctly. Simlilarly, take a state like South Carolina
and their judicial system. 70 of the counties (in term of
geography, not population) use a system that's antiquated
and writes out text files in Hex as their DB. The three
largest counties are using a State of the art system that
cna run on SQL Server, DB2 or Oracle. The former company
bends over backward to make sure their file format is
hidden so if a customer leaves, the next vendor will go
through h@ll.

My point? There is no possible technology that can
address issues like this. Standards on the other hand,
can handle it. XML won't do it because even if you have
XML, there are 6 different ways I could implement a field
like Name. And I don't think I will live to see the day,
that absent a standard, one can simply deal with some data
object that will know in advance enough things to
encapsulate everything.

Transparency of data is still growing and it's going to
take a while b/c everyone wants to keep a competitve
advantage. Think about it for a second, when a major
vendor in a fairly large state is still using a green
screen product and using Hex text files for a back
end...that's testimony to how far we have to go. (And I'm
not picking on SC by the way, it was just an example. I
can think of a few other atrocities out there like the
Veteran's Administration's Vista System.)

So in a nutshell, I think they are too different in too
many regards to really think of as absolute competing
technologies.

Cheers,

Bill
 
Back
Top