Microsoft.Data: Why It's Not All Bad

DZone 's Guide to

Microsoft.Data: Why It's Not All Bad

· ·
Free Resource
Earlier this week there was a post by David Fowler on a new Assembly for .NET: Microsoft.Data.  You can find it at http://weblogs.asp.net/davidfowler/archive/2010/08/02/introduction-to-microsoft-data-dll.aspx.  It was the subject of great ridicule to the point he had to write a prequel explaining the motive behind it: http://weblogs.asp.net/davidfowler/archive/2010/08/03/microsoft-data-dll-a-re-introduction.aspx.  I'll probably get flamed for this, but I want to get my two cents in.

So what is all the fuss about?  

You have probably heard buzz about Web Matrix and Razor and how it allows developers to have a lower point of entry into .NET.  Microsoft.Data is part of that strategy and adds the data component to it.  If you take a minute to look at David's post you will notice that he shows how you would do some basic data calls with plain old ADO.NET and then how do to the same with the new Microsoft.Data library.  There is less code and instead of having to work with a DataReader, you actually get an object back, pretty cool huh?  The problem that has caused all the fuss and fight is the fact that the query is inline SQL code in a string.

The arguments are mostly centered around that it is taking us back several years and teaching developers to use inline SQL code instead of at the very least using a data layer or an ORM tool, and thus not showing best practices.  I completely understand the argument and to be honest at first I was not real happy.  Not as livid as some people but wasn't happy about it at all.  I personally think that we need to do everything to teach developers how to do things the best way to ultimately produce the best, most maintainable code possible.

I want you to take a look back though and think about when you got started with development.  I know the books I learned C# and .NET from taught how to do regular ADO.NET development.  All the books showed you to use inline SQL, so that's what I did at first.  I came into .NET from PHP and ColdFusion where using inline SQL was the way it was done and there weren't many other options.  I didn't really like it, but it was what it was.  Having an ORM back then would have been awesome, but I don't know if it would have been the best option for me to start with.  I already knew SQL so it was easier to learn how to do data access in .NET using something familiar.  

Now here is the key to all of this for me:  I learned and grew past this way of doing things. I took the time to learn best practices around building proper data layers.  I rarely use anything but an ORM tool, normally Entity Framework.  There are so many problems that can come with using inline SQL and through learning saw those and adjusted my programming style accordingly.  We were all once beginner developers and this is who Microsoft.Data is targeted at.  While this does initially show techniques that are certainly not idea, not every beginner developer is going to understand or be able to quickly grasp things like repository patterns or object relational mapping tools.

So I said all that to say this:  Microsoft.Data is targeted to the beginner developers ( or at least beginners to .NET) and isn't for professional developers that know better.  While it is targeted at beginner developers, those developers need to know that this isn't a "best practice" and give them resources to learn about how to properly work with data bases in your code.  All developers start at level zero and only go up from there.  Giving them a tool that may make it easier for them to get started is absolutely a good idea.  The problem lies with not growing and learning past that so that the beginner styles make it into product applications where it can really cause harm.  Some developers will take that step and some won't.  I hope that most will but I know that several won't.

Bottom line is that training wheels help people get started riding a bike and it's a perfectly accepted method of helping someone learn.  It's when those training wheels don't come off that the issue is there.  I don't personally have a problem with the concept of Microsoft.Data as long as enough effort is made to ensure that developers have the information they need to grow past it.  Flame on.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}