System.Data Reformation
I don’t feel like there are too many netcasts about .NET. In fact, I can’t recall downloading the motion picture about how to approach System.Data. No “Patterns and Practices” show there. Back, say, in 2003 there should have been an ADO.NET Show about the “factory” approach to data connectivity. Yes, I’m sure there have been a few passing comments about data factories. Yes, there were plenty of written articles about this approach. “Provider-Independent code simplified in ADO.NET 2.0” is a fine example. But there is something about a passionate human voice out there that respects Microsoft but also respects the fact Microsoft is out to make money—and is not inclined to promote using the Sy``s``tem.Data.Common namespace over the System.Data.SqlClient namespace. There should have been an entire show devoted to this.
The assertion here is that it is responsible to write as much plumbing code as possible in the System.Data.Common namespace. The assumption here is that, by doing this, your code will be more flexible and portable to, say, Linux running Mono. For those of us who used ADO back in the days of COM “love,” we can feel like we are ‘using ADO.NET’ when we are writing with the Sy``s``tem.Data.Common namespace. So instead of .NET being a vast, huge, monolithic sea of Redmond campuses we can pinpoint the ADO.NET team and have a working relationship. And, yes, I know the ADO.NET team has a Blog but somehow I’m here writing about not hearing enough from the ADO.NET team. My guess is that they are prioritizing in favor of Entity Mapping and being sympathetic to LINQ.