Microsoft’s Eric Meijer spoke at QCon about “LINQ 2.0” in his keynote. So what on earth is LINQ 2.0? The name is probably inappropriate; he explained to me later that it is just a convenient tag for “what comes after LINQ 1.0”. Meijer started by talking about integrating relational concepts into languages; he didn’t say exactly what this would look like, but the idea is that you could specify relationships between objects, independent of the objects themselves. This is not LINQ 2.0 though; perhaps it is LINQ 1.1. LINQ 2.0 is about simplifying multi-tier, cross-platform web applications- hence the title of the talk, “Democratizing the cloud.”
So how do we do that? The starting point is that users want the same experience everywhere, irrespective of computer platform or device. Meijer’s idea is programmers should be able to code for the easiest case, which is an application running directly on the client, and be able to transmute it into a cross-platform, multi-tier application with very little change to the code.
So that’s the cross-platform runtime sorted. What about the programming side? How do we make our single-tier VB.NET application into a multi-tier web application?
Meijer talks about growing the application organically using refactoring. His use of the term “refactoring” is wrong I think; refactoring is meant to leave functionality unchanged. He means something more like re-purposing. You would take a method and add an attribute to convert it to a web service. Of course ASP.NET already has this (WebMethod attribute), but Meijer’s idea seems to include greater intelligence about the plumbing behind the exposed method. He believes programmers should only need to think sequentially, even though in reality web applications may have multiple entry-points and users may do things like clicking the Back button.
Meijer applies the same thinking to concurrent programming; developers should be able to do this with simple attributes, rather than struggling with synchronization statements and the like. Similar logic applies to state handling: Meijer reckons programmers should be able to program statefully, and have the infrastructure deal with the problems.
We should give programmers the illusion that their servers are stateful, while we can implement that in some scaleable way. That should be done once instead of all programmers trying to solve that problem.
I chatted to Meijer after his session. He emphasised that there is no roadmap for implementing “LINQ 2.0”; he is merely sharing some research thinking. What I’ve described above may never be implemented, or may evolve into something very different. Some parts sound fanciful to me. Will the idea of compiling IL for different runtimes really fly? Is it feasible to reduce multi-tier programming to a few attributes? Will this be any better than DCOM, which was meant to make distributed objects easy, but proved more complex and less robust than had been hoped?
That said, there’s little doubt that advances in programming will be about introducing new levels of abstraction, which may well provoke scepticism among old-school developers. This has happened before. I respect Meijer for what strikes me as good work in LINQ 1.0, so I’m paying attention.
8 thoughts on “Getting to grips with LINQ 2.0”
I have my severe doubts about some aspects of this LINQ approach. After having attended the MSDN Roadshow it struck me that LINQ might, in some cases, be encouraging bad practice. The kind of bad practice I have in mind is where somebody puts all the data access and business logic code in the client simply because the development environment allows it.
Where I work, if we are developing a large database application we put as much business logic and data access code as close to the data storage as possible, in stored procedures. It’s easier to maintain, much better performing (as optimisations can be done with reference to the underlying data) and generally more robust.
I suppose we will just have to wait and see how it all works out.
> The kind of bad practice I have in mind is where somebody puts
> all the data access and business logic code in the client simply because
> the development environment allows it.
This is a longstanding problem with Microsoft’s tools. But it’s not inherent to LINQ that you would put the code in the wrong place. As for sprocs, that is another debate entirely 🙂
Well, I’m open-minded about it. One thing that’s very good about LINQ is that it brings relational concepts to client-side programming.
Another database-originated feature I’d like to see on the client is proper support for transactions. Imagine how much easier it would be to write, say, an installer script for a package if you knew you were going to be targeting a transaction file system. 🙂
Thanks for the eloquent review of Erik’s keynote presentation.
My project jsc does exactly this. 🙂
Yet the jsc project is still in child shoes, but it really works.
The jsc project is very interesting, thanks.
Nikhil Kothari from the ASP.NET team has already built something along the lines of the Google Web Toolkit http://projects.nikhilk.net/Projects/ScriptSharp.aspx
I’m not entirely sure the world needs a lot more AJAX though. Usability, accessibility and performance are usually afterthoughts. I think these have traditionally been a problem for the ASP.NET community anyway.
Regards LINQ and doing things the right way, I’d tend to agree with the sentiment but not with use of stored procs. Performance with a good OR/M tool like LLBLGen is as good or a little less than use of stored procs with much better productivity. In my experience it also reduces the pain for people upgrading your application.
I guess best practice would say you should use Linq where you currently have your data access layer. Most of my app UIs only ever see custom objects, not datasets or the like.
Some “very large scale applications” (eg. web 2.0 sites) have found a lot of drawbacks in relational databases – this is where LINQ V.Next may be looking. Google released an extension of the Hibernate framework that allows you to query shards of data that are spread across many servers (or [web]services). I could see Linq following along the same lines.
I have no idea if this type of stuff is really going to be that useful for the majority of developers out there. esp. if your application data cannot traverse the company firewall, or you have limited support infrastructure/people to handle network outages.
Brian I think I just finished reading the follow up to that at http://www.linqhelp.com
Comments are closed.