Misc Thoughts on ADO.NET 2.0

Out of everything in .NET, ADO.NET is unquestionably my favorite.  Naturally, I was really excited about ADO.NET 2.0-- it has such a poweful feature set and addresses so many 'shortcomings' of the current model that I'm already rewriting a few of my current apps to take advantage of them even though we are a year away from release.  But I'm getting really apprehensive about a few things and I have to wonder what Microsoft is thinking.  Two things come to mind with the first one being much less important.

There a new object called the Resultset. What is a resultset?  It's a capitulation to every VB6/ADO developer who's spent the last year cramming connected squares down disconnected circles.  It's also a powerful tool to help bridge the ambiguous grey area between the black connected model (datareaders, Command.Executexxx) and the white disconnected model (DataSets/Datatable/DataView).  I've seen it, use it regularly, and think it's great.  I also think it will be the second most improperly used object in ADO.NET 2.0.  Why?  It's too easy to say “I'll do what I'm accustomed to and use this thing” b/c  it's the closest thing to a Recordset their is.  Logically even more than physically, this is the Recordset all grown up.  And that's the whole problem.  ADO.NET wasn't supposed to be ADO.NET all grown up.  It was supposed to be (and currently is) a whole different DNA strand.

This bugs me to say b/c the cure (not releasing it) is just as bad as the disease, no better no worse.   But in the overall context of what's going on here, I see some real disasters on the horizon.  Why?

Well, couple this with Notification Services.  NS is without a doubt a totally kick a55 implementation and it's so cool it defy's words.  In the disconnected world, it will tell you that something has changed since you called .Fill on the dataadapter.  This is one of the most commonly asked questions I see out there “I don't want to poll the db, so how can I tell something has changed without sending back an .Update?”  But Notification Services isn't cheap.  And it's too easy to use (no, I'm not advocating making it artificially hard).  I probably sound like the world's biggest technology snob so let me explain why.

1)  Head over to your favority .NET newsgroup that includes a good amount of VB.NET programmers (particularly ones just coming from .NET).  Count the questions directly related to Option Strict being off.  Point out that weak typing introduces subtle bugs, ones which aren't detected until the customer starts using the product.  Then suggest the solution (fix the typing problem and turn on Option Strict).  Sit back and wait to hear what  a jerk you are and how that's not what they asked you and that's not how they did it in VB.NET and how .NET sucks donkey parts etc etc etc.

2)  Head over to your favorite ADO.NET ng and count the number of posts that have “Problem updating DB” in the text or title.  Add one point for each one that is caused by a commandbuilder used on a table with no Key.  Add 5 points for each one that had a Try Catch block which does nothing but obscure the problem.  Add another 3 points for each one where an update is being called on a datatable with no data.  Tack on 7 for each one that has .AcceptChanges being called right before Update.  Add another 10 points for each grid, bound to a datatable, where the user is calling sort on a dataview based on the datatable which isn't working.  Add another 10 for each one where .HasChanges is false.  Add 15 points for each one where a join query was used in the Select statement and has a Update/Delete or Insert command that also has a join in it.  Add 50 points for each instance of Dynamic SQL being used that has an apostrophe in it that the developer 'forgot' to escape but who doesn't want to hear about Parameters or stored procedures.   Add another 30 for each use of a DataReader where Ouput params would have worked better.  Add another 25 points for each each question where the update is failing b/c it includes a Reserved word in it. Add another 50 points for each instance where someone rolls back a transaction after a failed update but noticed the rowstate of his rows haven't been changed back.   Add another 100 for each developer that wants to use procs but sin't alllowed to

Subtract 25 points if they accept the Parameterized or Stored proc notion.

Subtract 100 points for each user that can name 1 EVENT of the connection object and use it in a sentence. 

Subtract 75 points for each person that can tell you waht .AcceptChanges does

Subtract 100 points for each person that can idenitify the conditions under which an adapter will submt the changes.

Mail me the difference in $1.00 increments.

I don't know... I love ADO.NET and can't wait for it, but I think all the cats yearning for VAL, and being able to easily access controls on other forms and using dynamic sql and all that jazz are going to have a lot of fun with this stuff.

The same type of fun most teen aged boys would have with their dad's new Porsche, a bottle of Whiskey and empty houes over the weekend replete with Pop's Amex cards  assuming they were told to handle these things maturely.  Ask anyone in my family how this ends up.  Heck it wouldn't even have to be teenage boys.  Let me and Casey cruz around in Gates' Porsche with his amex card, we'll be glad to give you  a precursor.

I better quit whining and start getting ready writing new articles.

Bill

www.devbuzz.com

www.knowdotnet.com