A few interesting things have happened at Microsoft lately. They have talked about the features in the next revision of the .NET CLR.
First of all, I am not talking about .NET 3.0 (WinFX) – I don’t like to see that as a new release of the framework. Frankly, I feel they have caused a lot of confusion with naming the framework 3.0. In my recent trip to Redmond, there was a gentleman sitting next to me who was evaluating the upgrade to .NET 2.0 from 1.1. He manages a team and a product at a company - and he was shocked to hear that .NET 3.0 != CLR 3.0. I don't think he was dumb, I think MS Marketing is dumb in it's inability to communicate properly, or let us say their ability to confuse their customers.
People are too busy solving real business problems, and it is extremely hard for us consultants to communicate clearly that .NET 3.0 is really .NET 2.0 with some extra goo. Remember, the audience for these strategy level changes can be managers who do not have the will or time to understand what “CLR” means, and why .NET 3.0 is not CLR 3.0.
Seriously Microsoft marketing – what were you thinking there!?!
Now with my slight detour, I’ll get back to what this blog post is about. Microsoft has been talking about a few ground breaking changes lately. As much as I detest the WinFX name being changed to .NET 3.0, and as much as I am convinced that Microsoft marketing made a mistake there, I am quite excited about what the “true” .NET 3.0 was going to be, and which I am forced to call .NET vNext because of this naming confusion Microsoft caused.
Seriously – let me get off the criticism bandwagon and get back to what this blog post is all about. In the past few months, Microsoft has talked about adding querying ability to .NET languages. Some ultra smart guys like Anders H and Don Box sat down and discussed what would they need to do to the underlying framework to give it querying abilities. So they proposed a number of changes, which would serve as the foundation for LINQ, or Language Integrated Query.
I have previously blogged about these specific changes. You can see these here –
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) DDemystifying C# 3.0 - Part 6: Expression Trees
I’ve said it before and I’ll say it again – “Data is the king”. You are writing your application because someone has some data to be managed, it isn’t the other way around. People won’t produce data because you feel like writing an application. As a result, the two places where data is directly dealt with in the framework – XML and Database oriented data access were the two perfect candidates for further feature-ification of LINQ.
Thus came XLINQ (now LINQ to XML) and DLINQ (now LINQ to SQL).
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.
Of course, you had better chances of finding a hot bikini model who was also a C++ programmer, than to find an application where the logical and conceptual model would be the same.
Thus, I (and this is only me), am postulating that LINQ to SQL will meld/morph/give way to ADO.NET eF.
The obvious question is – What does this change do to your architecture?
So Datasets? Business Objects? Or just LINQ?
That is the question!! And that is what I am talking about at VSLive next Monday. In subsequent blog posts, I am going to rile up a discussion here offering a sneak preview of what I feel .NET vNext will do to your architecture.
.. at the very basic, I feel it is about bridging architectures.