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.