A short take on Microsoft.Data

  • Article

Yesterday, David Fowler blogged about the Microsoft.Data APIs that come with ASP.NET WebMatrix.  While there were some positive comments, the majority were negative.  The reason for that is that a lot of readers completely missed the point of the API.  David is partially to blame for that, as he had not properly put it into context.  He since wrote a follow up post which fills in those gaps (and here is another one by Andrew Nurse), but I’ll try to do a slightly different take on this.

So in what sense did some readers ‘miss the point’?  They read it as:

Microsoft is now recommending a new data API. That API uses raw SQL rather than an ORM. Bunch of Microsoft idiots, what are they thinking!? :)

The reality is of course quite different.  As great as ORMs are, there is a measurable number of web developers who favor writing raw SQL over using an ORM.  That is a fact, and if you’re trying to pretend that it is not the case, you’re in denial.  Though they tend to be less vocal, there are a lot of people who prefer the raw SQL approach, for a variety of reasons.  But the point of this post is not about whether one should use an ORM vs raw SQL, as enough blood has been poured over that. :)

Instead, this post is about this new Microsoft.Data API.  Here is a one liner that describes its goal:

Given that someone will use raw SQL, how can we make it easier.

The first part of the sentence is key, and is what makes all the comments along the lines of “they should not use raw SQL because … ” completely moot.  Simply put, if you are an ORM user this technology is not for you.

Instead, the only relevant way to look at this API is to discuss whether it is indeed an improvement over the old ADO.NET API.  And in my opinion that is no brainer.  Pretty much everyone who has seen it in this light has agreed.  Among the advantages over ‘classic’ ADO.NET:

  • It uses far fewer concepts to achieve the same things.  Having to deal with SqlConnection/SqlCommand/SqlDataReader can be overwhelming.
  • It makes it easier to use parameterized queries, hence reducing the risks of SQL injection issues (Andrew’s post has some simple examples).
  • It uses ‘dynamic’ to make it more natural to access row values.

Is it revolutionary compared to classic ADO.NET?  Clearly not, and no one claims that!  But it is a long overdue simplification to the messy ADO.NET APIs, and in that sense it is pure goodness.

Now you can get back to your favorite ORM and feel safe that your world is not under assault. :)