wagnerblog.com

I swear that I could have mentioned this before…..

OK, picture it is four or five years ago and you are among the powers that decide how ADO.NET will be shaped. With all the new functionality ( especially oo-centricity of .NET) what would make you come up with such a thing as a Dataset. In one word - the 6 million or so VB developers that are used to recordsets. Sometimes it helps to know history so you won’t repeat it . Lets go waaaaaayyyy back to the beginning of this journey.

In the late 80’s the big software race was in the area of desktop database development. DBase was well entrenched and FoxPro was gaining ground all the time. Clipper was not to be left behind either. And as great as these tools were, they were not Windows based products. So whichever company releases the first Windows application desktop DB would take a large chunk of the market. MS realized this and had been working on a database engine that could be the backend to several Windows products. This engine was called Joint Engine Technology (JET). It was the backend for Access and approximately 18 months later for VB 3. Prior to JET , VB was only a language. With the addition of database capabilities VB became entrenched as the major tool of choice for corporate developers.

JET itself was an amazing step forward in technology. It contained all the prerequisites of a true RDBMS and it was able to deal with severa datasources. In addition, for developers it presented a giant leap forward by enabling programmers to work with resultsets in a completely new fashion. One day the team lead of JET, an Indian gentleman named Nurinda Vrama had a brainstorming session with his team on the topic of what to call this new “dynamic” resultset. Right about the same time Tod Nielsen walks in - the same Tod who just left BEA and maybe headed for Google. In those days Tod was VP of Developer Tools at MS. He walked in and asked what the brainstorm was about. Hmmm. A dynamic resultset? What should we call that… hmmm…. dynamic resultset… dynamic set…. DYNASET ! That’s how the term was born . Programmers who go all the way back to the early days of Access / VB may remember it.

With the advent of ODBC the dynaset became a RECORDSET, while still maintaining its primary characteristic of being a “table-type” object. Time passes and MS releases RDO which was later followed by ADO, all the while never straying from the path of table like data objects. The more time passed the more tools in MS’s product suite would work directly with these table type objects. Of course the mainstay for developers being VB. Ergo databinding in VB or Access or Excel or C++ involved some sort of control that was able to receive a RECORDSET.

So here it is a few years later and MS works on .NET. With all the OO possibilities available in .NET there had to be a discussion that tookplace at some level that outlined the need to continue the old tradition of table type access. I imagine someone might have pointed out that .NET could easily handle data access and databinding in the same manner as Java did - by filling business objects and collections. Somewhere the decision was made that it was probably easier to move the 6 million VB developers into the new and bright world of .NET by continuing the tradition of table type access. Hence the idea of the data table. From there it wasn’t too far to gain acceptance of the Dataset. Even though a Dataset (strongly typed or not) is an odd beastie.

So there is my hypthesis - Datasets gained acceptance because they make it easier for VB coders to work with ADO.NET as opposed to dealing with the vagaries of typical OO multi-tiered object/collection architectures. It was purely a business decision. (After all some of the problems of datasets have been widely documented). Don’t get me wrong, I like them just fine for smaller or mid sized systems that need to be built quickly, but for larger scale applications a good object model can’t be beat.