Microsoft.Data.dll - A re-introduction

Before we look at the reasons for the existence of Microsoft.Data, we need some background on the WebMatrix initiative. Here are some excellent blog posts that describe the type of audience we are going after and the goals of the project:

http://weblogs.asp.net/scottgu/archive/2010/07/06/introducing-webmatrix.aspx

http://blogs.msdn.com/b/davidebb/archive/2010/07/07/how-webmatrix-razor-asp-net-web-pages-and-mvc-fit-together.aspx

http://geekswithblogs.net/mbcrump/archive/2010/07/06/the-forrest-gump-guide-to-the-new-webmatrix.aspx

These blog posts point out that WebMatrix targets a different audience than our traditional pro developer audience. These are people who are not yet developers (if they ever plan to be). They may never want to become a pro developer, but want to be able to put together a simple website. If you've internalized best practices and patterns and know your way around an ORM, then you will most likely never use this library. We are trying to attract a different kind of customer: people who are on other platforms and are already using SQL today in their web pages, and people that are trying to get into programming and haven’t chosen a platform as yet.

Most likely, if you're even reading this, you're not the intended audience, though we are still interested in your feedback.

Why Microsoft Data?

Scott Gu quote:

We've debated the role of ORMs for entry-level devs quite a bit (and have a dynamic ORM implemented - but which we didn't ship with today's preview).  For someone who understand objects and classes they can be great. When we brought in web developers to use the product for a few days, though, one interesting data point that came up repeatedly was that about 80% of them had never even heard the term "ORM".  We found it took awhile for them to conceptually grok it - whereas adhoc SQL came much easier to them. It is something we are going to continue to work on finding the right balance on.

I could not put this any better. We didn’t immediately decide to go with SQL, but after going through several options, we decided it was the simplest way to go.

Absolute beginners won’t have Visual Studio, and most of our existing data stack relies heavily on tooling support (designers, and code generators). We wanted to build something that felt like it could be authored from notepad.

Who Is it For?

Nikhil has a good blog post on personas http://www.nikhilk.net/Personas.aspx:

Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems and focuses on productivity and learn as needed. Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learn while working on the solution. Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem, and typically learn in advance before working on the solution.

WebMatrix is trying to target beginners (like Mort, or pre-Mort). By beginners I mean, people that:

  • May not understand generics (or don’t care for them)
  • Do not care about TDD, DRY, SRP, (insert acronym here)
  • Do not understand lambdas or expression trees.
  • May not have any knowledge of OOP

I could go on and on, but the point I am trying to get across is that if any of this sounds absurd to you or if it offends you in any way as a developer, then you are probably not the target audience.

This post can be summarized by the following quote from Scott Gu’s blog:

If you are a professional developer who uses VS today then WebMatrix is not really aimed at you - at least not for your "day job".  You might find WebMatrix useful for quickly putting a blog on the web or doing lightweight scripting on the side.  But it isn't intended or focused on hard-core professional or enterprise development.  It is instead aimed more for people looking to learn how to program and/or who want to get a site up and running on the web without having to write much code.

Published Tuesday, August 3, 2010 9:27 AM by davidfowl

Comments

# re: Microsoft.Data.dll - A re-introduction

Tuesday, August 3, 2010 12:45 PM by Troy Goode

"When we brought in web developers ... 80% of them had never even heard the term 'ORM'" -- ScottGu

Really? Who are these "web developers"? How are you selecting which developers you bring in to use your products?

My guess: the local SharePoint user group.

# re: Microsoft.Data.dll - A re-introduction

Tuesday, August 3, 2010 12:47 PM by kristofera

<i>"These are people who are not yet developers (if they ever plan to be). They may never want to become a pro developer, but want to be able to put together a simple website."</i>

This is exactly why people take an issue with the Microsoft.Data approach. If they are not developers then SQL-in-strings is an excellent way to invite trouble for them. (Not even taking into account that bringing yet-another-language for them to learn adds another hurdle).

I can see what problem you're trying to solve: simple data access. You already have a great light-weight framework for that purpose: Linq-to-SQL. Something very similar to this could be built on top of the Linq-to-SQL runtime and that would immediately take away:

a) SQL-in-strings and the need for these non-developers to learn SQL on top of C#, Razor, MVC, HTML etc

b) The risk for sql injection

...add to that a visual designer / query builder and all the non-developer simple query scenarios could be done without needing to write a single line of code.

JMHO

# re: Microsoft.Data.dll - A re-introduction

Tuesday, August 3, 2010 12:56 PM by Bret Ferrier(runxc1)

I was surprised by how much flack you got over your first post.  Being an Elvis programmer I can only see using this in prototyping scenarios... well I guess maybe not even then as I would use EF Magic Unicorn as I prefer a code only experience for prototyping and like the way it can be used to create the database.  I guess maybe the only time I will use this is in trying to teach younger kids how to build websites.

# re: Microsoft.Data.dll - A re-introduction

Tuesday, August 3, 2010 2:20 PM by Jarda Jirava

Hi, when you are thinking about web developers you think about developers with MySQL knowledge. But, the syntax is "little bit" different then in MSSQL (CE) so for these developers it's not possible to construct right query for their usage. In this manner it's fine to have any ORM (Linq2SQL or maybe better light EF from CTP4) that construct the query.

In this context it will be better to have something what has LinqPad - automatic creation of context with strongly typed properties. Or to have something "new" that's based on NoSQL database where is possible to define entities and use it (with LINQ) - you have this in Azure so why you don't use this?

-- J. (sorry for my english)

# re: Microsoft.Data.dll - A re-introduction

Tuesday, August 3, 2010 3:22 PM by Jason Y

kristofera hit the nail on the head.  This is only an invitation for trouble, not at all a way to get a site up-and-running faster.  It's like giving poison to kids on Halloween and saying it's for "those who don't care about their health," or a doctor giving alcohol to alcoholoic patients as a pain killer because they "don't care about" the repercussions.

TDD, SRP, etc. aren't mere preferences, nor are they just for the elite.  They are for those who want to write more and better software in less time.

# re: Microsoft.Data.dll - A re-introduction

Tuesday, August 3, 2010 5:57 PM by Andy Edinborough

There a ton of old as dirt databases that would be absolute HELL to try to move to an ORM, and it would be impossible to justify the massive code changes necessary to go back and update all the existing code.

There is most definitely still a place for this level of access and I'm glad to see it.

# re: Microsoft.Data.dll - A re-introduction

Wednesday, August 4, 2010 4:07 AM by Rob Bowley

"It is instead aimed more for people looking to learn how to program and/or who want to get a site up and running on the web without having to write much code."

Firstly, if I wanted to build a website really fast I would use Ruby on Rails, end of story.

Secondly, there is very little value in using this tool for learning if it does not consider TDD, OOP or any good coding principles to be important. I certainly would not want someone who learnt web development via WebMatrix coming to work at my company.

# re: Microsoft.Data.dll - A re-introduction

Wednesday, August 4, 2010 5:37 AM by mohammedsameer

I would not call people with no OOP knowledge and do not understand generics developers.

So this is basically a utility to allow people without development skills to write code and bring the industry to a new low.

# re: Microsoft.Data.dll - A re-introduction

Wednesday, August 4, 2010 12:37 PM by RichB

@troy I don't think you inhabit the real world of software development. I'm a consultant who has spent time in more enterprises than I care to think about. In a lot of places, the developers haven't even heard of StackOverflow.com - so ORM, IoC, TDD would all return blank faces.

Yes, it's a shame. And the solutions delivered by these developers are worse because of it. But it's reality.

# re: Microsoft.Data.dll - A re-introduction

Thursday, August 5, 2010 4:22 AM by Mohamed Gouda

I think that Mort, the opportunistic developer and his similar, will find a good vacancy at Microsoft

# re: Microsoft.Data.dll - A re-introduction

Thursday, August 5, 2010 6:13 AM by Harry McIntyre

Is there any way we can test this code once we get told to fix it? Database.OpenFile isn't the world easiest thing to mock.

Can we write our own Providers and change provider at runtime?

# re: Microsoft.Data.dll - A re-introduction

Thursday, August 5, 2010 6:26 AM by Craig D

I'm sorry but that still doesn't justify inline SQL. Let's even ignore the security risk that you're allowing unknowing developers to implement, which I thought goes against the whole Microsoft secure by default issue.

A noob isn't going to know complex T-SQL either!

A 'default' EF context wraps a db in a one to one ActiveRecord pattern. To an amateur developer that's going to look like Table.Column 1:1 as Class.Property, which is waaaay easier to deal with that SQL.

It's a no brainer.

# re: Microsoft.Data.dll - A re-introduction

Thursday, August 5, 2010 6:21 PM by Marcus Wendt

"When we brought in web developers to use the product for a few days ..."

I guess you will bring in web developers to test out this stuff also, and you will probably find that quite a few – tasked with ‘output the product title being requested via the URL’ - will paste/write code like this:

using (var db = Database.OpenFile("Northwind")) {

   foreach (var product in db.Query("select * from products where id = " + Request["id"])) {

       Response.Write(product.ProductName);

   }

}

Would you call that “success” or “failure”?

I would say that the person writing the code will feel like he succeeded, but the tooling failed him big time. I can sympathize with your intent, but this is like giving a small child a razor sharp butcher knife telling him he can now do origami. Passing strings to a command interpreter is a serious matter and I’m quite baffled that we are even having this conversation.

It’s a “redo”. I’m all for your intent of empowering people and in general that is a positive trait of the technologies you release, but you somehow left out your security reviewers on this one. At least run it by them. Please!

# re: Microsoft.Data.dll - A re-introduction

Thursday, August 5, 2010 9:37 PM by Marcus Wendt

Couldn’t you do something like

var result1 = db.Query("select * from products where UnitsInStock < {MaxUnits}",

                      MaxUnits: 20 );

var result2 = db.Query("select * from products where Title like {KeywordMatch}",

                      KeywordMatch: "%"+keyword+"%");

var result3 = db.Query("select * from users where password = {Password} and user = {User}",

                      Password: "secret",

                      User: "root");

Protect the poor novice developers by explicitly denying values in the sql template, reflect on column types and handle string delimiters / validation accordingly. If perf is a concern have some switch somewhere. Anyway the syntax above is easier on the eye than the usual string concatenation/replace goo. And I get to keep my impression of Microsoft as the company that managed to get security right through hard work.

# re: Microsoft.Data.dll - A re-introduction

Tuesday, August 10, 2010 10:47 AM by Mitch Labrador

When it comes to concept complexity. What's harder for a new developer to learn, how to avoid SQL Injection attacks by using parameters or teach them NHibernate, EF, or LinqToSQL?

SQL has been around for such a long time because it is efficient and very friendly. SQL Inj. attack prevention techniques are a very simple thing to teach to a new devs as supposed to teaching them an ORM stack.

# re: Microsoft.Data.dll - A re-introduction

Thursday, August 12, 2010 12:59 AM by Stephen Walsh

"Microsoft.Bob.Data.dll"... very good and sums it up nicely.

# re: Microsoft.Data.dll - A re-introduction

Wednesday, August 18, 2010 12:01 PM by RussellH

It is possible to use parameterized SQL with this framework?  If not, you cannot really, fully protect against SQL injection.

# re: Microsoft.Data.dll - A re-introduction

Tuesday, November 16, 2010 5:25 PM by Mike

I can't believe it...

"[we] have a dynamic ORM implemented"

"we decided [SQL] was the simplest way to go."

It's a cop-out, it's a failure, you will be sorry for it, the Mort persona should NOT do development and should NOT be allowed to set the agenda and worst of all, the community will suffer for it. Great move guys!

Hope you guys reconsider the dynamic ORM.

# re: Microsoft.Data.dll - A re-introduction

Tuesday, November 16, 2010 5:28 PM by Mike

Maybe you could call the software:

Microsoft Mort

"If you are to lazy do read a book Microsoft has just the tool for you! Why learn about development when you can start writing crap code NOW? Why invest in a skill when you can deliver insecure code NOW? How do you spell O-R-M? Who cares?! Get WebMatrix, it's free!!"