A Discussion on ADO.NET
Those of you who know me no doubt know that I'm an ADO.NET nut. To date, I can honestly say that i've read every ADO.NET book out there, at least as indicated by Amazon.com and the major publishers. I'm pretty active in the MS ADO.NET Ng (not the last two weeks but other than that...) and it's nothing for me to put up 900+ posts/answers in a month. Greg Low had this interesting take on Bill Vaughn's ADO & ADO.NET Examples and Best Practices for VB Programmers (he's also got the same book done in C# with Peter Blackburn- although the title is changed to “...For C# Programmers”) book. I'm a big fan of Vaughn and read everything he puts out. From the looks of his pieces i've gotten on his new Sql Server Reporting Services book, he lives up to expectations again. Anyway, Greg mentions that he has a few differing opinions with Vaughn on the use of the .GetOrdinal() method of the DataReader as well as some other issues on DataReaders in general and Typed Datasets. He didn't get into what they were but I asked him to elaborate on what those were b/c they'll surely be interesting. Anyway, if you aren't familiar with it it breaks down like this.
If you use the Column Name with a datareader ie dataReaderName.Getxxx(”ColumnName”) then the runtime needs to resolve the Column's index at each pass. Since DataReaders are usually intended to high performance data access, you want to squeeze out every bit of performance you can get. However, using Getxxx(0) isnt' the most readable thing in the world, even if you document what 0 is. So the reader has a GetOrdinal method which lets you do something like int iClearColumnName = dataReaderName.GetOrdinal(”ColumnName”); and then you can reference it in code like this : readerName.Getxxx(iClearColumnName) - hence giving you the best of both worlds. Vaughn's contention is that GetOrdinal has some overhead with it and you already know the index of the column name by virtue of the SQL Statement. To those that would say that you don't if for instance you are using Stored procs, well, you would have the know the column's name anyway so you should, or can easily find out, the position. As such, you can create an enum with each of the colum names, reference those the same way you would using getordinal and have the best of both worlds without any overhead associated with GetOrdinal. I'm a performance freak - but as I mature I realize that readability is every bit (and often more) important. GetOrdinal seems like a great compromise but Vaughn's idea seems even better. I'm not sure if this is Greg's issue but I'm dying to find out.
As far as typed DataSets... well, this seems like an open and shut case. If you know the structure of the query in advance, USE Them. They are faster, cleaner, have intellisense support etc. If you don't know the structure, then you have no choice, you have to use an untyped one (technically this isnt' true but the workaround is more work than it's worth in my estimation so I wont' get into it). I'm also intrigued to see what Greg's viewpoint is here.
If you spend as much time studying something as I have ADO.NET (and making mistakes and mistakes and mistakes), it's easy to think your opinions are 'right' - hell I know a lot of people that are ignorant as hell on a lot of things and they think their opinions are facts. But to truly know something, it certainly helps if you know every angle on the thing, the upsides and downsides from every perspective. As such, I'm really intrigued in what Greg has to say - Or any of you for that matter.
BTW, if you need any recommendations on ADO.NET books (or .NET books in general), I can probably be of assistance. My man Phil has just given me some great recommendations on Patterns and although Borders didn't have all of them, I'm going to pick all of them up - I got three of them already. Patterns is defintely something I'm not that strong on - something I intend to fix ASAP. I've also been doing a LOT of work with ADO.NET 2.0 and trust me, there's a lot. So far, I don't think it's a stretch to say that learning ADO.NET 2.0 if you know 1.1 is about as much work as learning ADO.NET was from ADO. 2.x . Much is the same, but there are a ton of new features (I'll write more tonight) and there's a LOT of thinking you should engage in before hacking away at it - then again, what else is new?