I wanted to jump in with my $0.02 (Canadian ) on Microsoft.Data.  David Fowler, fellow ASP.Net team member, posted about it earlier today, and the response has been ... active .  The message behind most of these responses has been that it encourages bad practices to novice developers.  I think there's an important point that's being missed here: It doesn't matter how hard we work, as professional developers, to create clean architectures and abstractions, there's a whole world of novice developers who just don't care about that.  They want to write code now and be done with it.  This is the audience targeted by Microsoft.Data, and the WebMatrix product as a whole.  If novice developers come to the Microsoft platform and see these complicated architectures (which, don't get me wrong, have massive benefits for professional development), they simply won't adopt them, they'll just head to a different platform which allows them to get their job done quickly.

Microsoft.Data is, in my opinion, actually a step in the right direction.  For example, let's say I'm a novice developer, and I go out and look for samples and documentation in order to piece together a simple product list from my database.  As long as we do our work right (and we plan to), the documentation will lead me to write something like this:

@{ var products = db.Query("SELECT * FROM Products WHERE CategoryId = @0", categoryId); }
@foreach(var product in products) {
    <li>@product.Name</li>
}

It works, and it's SQL Injection safe.  Note that although David didn't blog directly about this, Microsoft.Data fully supports parameterized SQL and it actually supports it better than traditional ADO.Net (note that I don't have to fiddle with SqlParameter objects).

Now, I'm learning more about proper architecture, and I decide to switch to an ORM and use Linq for my queries.  A quick one-liner change and I'm all set:

@{ var products = db.Products.Where(p => p.CategoryId == categoryId); }
@foreach(var product in products) {
    <li>@product.Name</li>
}

[NOTE: WebMatrix doesn't include a true ORM, as there are plenty of good options out there, this is just a sample of how one could ramp up from Microsoft.Data to more powerful ORMs]

And if I want to go full-tilt and use ASP.Net MVC, I can move my data access code into a Controller (or even deeper into my architecture) and then a bit of copy-pasting gets me to:

public ActionResult Products(int categoryId) {
    var products = db.Products.Where(p => p.CategoryId == categoryId);
    return View(products);
}

@foreach(var product in Model) {
    <li>@product.Name</li>
}

From there I'm free to keep refactoring things behind further abstractions (Repository patterns, etc.). I've started simple and refactored as necessary to improve the architecture. In every step, I've been able to take a lot of the existing code with me, which traditional ADO.Net and other platforms (like PHP) don't make quite as easy.

The simple fact is this: The audience we're targeting is already using inline SQL, they are perfectly happy to keep doing so and they are not interested in clean abstractions (to the point of finding them complex and unnecessary).  Microsoft.Data, and the entire ASP.Net Web Pages framework (the inline page model used in WebMatrix), is an attempt to provide a simple model for web development that provides on-ramps to guide users towards best practices.