ADO.NET vNext, the missing piece of .NET vNext.

Posted on 8/15/2006 @ 3:39 PM in #Vanilla .NET by | Feedback | 3019 views

Microsoft has been talking about what will be the next revision of the .NET CLR for a while now. They introduced a number of features in C# 3.0, which had one thing in mind “Data”. Making working with Data was made easier by introducing LINQ, or Language Integrated Query. I have blogged about this at numerous times myself, notably the following posts:

a) Demystifying C# 3.0 - Part 1: Implicitly Typed Local Variables "var"
b) Demystifying C# 3.0 - Part 2: Anonymous Types
c) Demystifying C# 3.0 - Part 3: Extension Methods
d) Demystifying C# 3.0 - Part 4: Lambda Expressions
e) Demystifying C# 3.0 - Part 5: Object and Collection Initializers
f) Demystifying C# 3.0 - Part 6: (LINQ) Query Expression Translation (to C# 3.0)
g) Demystifying C# 3.0 - Part 6: Expression Trees

The obviously question after LINQ was, to address where your data lives. Well it lives in it’s home – the database, and camps out in its tent – XML. So there came XLINQ, and DLINQ. XLINQ, I feel is ugly and has limited application - so it's pretty much as good or bad as XML. (And before you rant and rail about how cool XML is, please read about a dangerous disease called - XMLitis).

But you can't ignore databases. So DLINQ has a much higher impact on your application than XLINQ does anyway. So I talked a bit about DLINQ:

Demystifying DLINQ: Part1 - An introduction to DLINQ
New Article: DLINQ: Bridging the Object Relational Divide
Demystifying DLINQ: Part2 - Setting up a DataContext Class
Demystifying DLINQ: Part3 - Querying for Data using DLINQ
Demystifying DLINQ: Part 4 - Stored Procedure/UDF Support in DLINQ.
-- Demystifying DLINQ: Part 4.1 - Stored Procedures that return scalar results
-- Demystifying DLINQ: Part 4.2 - Stored Procedures that return a definite shape
-- Demystifying DLINQ: Part 4.3 - Stored Procedures that return variable shapes
New Article: DLINQ: Submitting your Changes (Where I also talk about optimistic concurrency checks that DLINQ offers)

Now, I did an experiment of writing my blog engine using DLINQ. I ran into various issues such as every projection I tried creating was an anonymous type. And given that anonymous types must be declared along with their initialization (which is a good thing – see for more details), I had a problem converting them to structures that were disjoint from the database, and structures that were logical to my application. Also I had issues adding "smarts" to those anonymous types, and passing them across boundaries.

One of the most under-advertised features of DLINQ was the ability to extract the metadata out of the database as XML, and then twiddle with that XML, and then generate C# (or VB.NET) code out of that.

It still wasn’t quite what you need for real world applications, where your logical model could be sufficiently disjoint from the conceptual model. So DLINQ (now LINQ to SQL) was ideal for situations where your logical model was very close to the conceptual model. So basically it suited the two penguins that write .NET code in Antarctica. Clearly, we needed more.

And that is where ADO.NET vNext fits in.

I will be blogging about the various practical applied aspects of this new technology, and .NET vNext in the coming days. For now - Go Download.

Sound off but keep it civil:

Older comments..


On 8/16/2006 9:22:32 AM John Wood said ..
XLinq is pretty bad but probably not for the reasons you think it's bad. I think it just doesn't go far enough. There were very good reasons why XPath was developed and people aren't using SQL to query XML documents. But no, MS completely ignore that and refuse to integrate XPath into the language. It's a shame because I think Cw had far better XML/XPath integration than what XLinq gives us, so it has been proven as possible.


On 8/16/2006 9:36:40 AM Sahil Malik said ..
John -

XML is bad. LOL. :)

I think it is hella overused and very fragile and twiddly in many instances. The less I need to write XML myself, the better it is.

Working with XML, even in code, should be a bit like doing laundry - or say kissing your dad. We all have done it, but we make it quick, painless and we never wanna talk about it again.

Anyhow, no specific comments on Cw vs. XLINQ though. Maybe you should blog about the specific differences?

Sahil