I’m gonna come across as defending MS here, but really I just think this assesment of LINQ from Frans Bouma is just completely off base. LINQ has nothing to do with ORM at its core, instead it enables richer ORM scenarios with natural language query extensions for developers.
If you want to talk about DLINQ, well that’s another story, but then you’re talking about a layer built on top of LINQ and it is a completely separate beast and some of us have already had that discussion over on Paul Wilson’s blog. That said, I realize that most of the demos were done with DLINQ so it can kind of blur the lines and make it hard to see the distinction between the two, but what’s important are the core, abstract concepts:
- Query any IEnumerable<T>
- Can use natural query language syntax OR just use explicit delegates
- Ability to do projection and still work with a static type (really this is just a feature of the language, but it absolutely core to LINQ’s success)
- Complete query API extensibility using custom extension methods
- Expression trees enable product writers to proxy queries through to back end for efficiency (e.g. turn into SQL or XPath query for max efficiency over underlying store)
I don’t understand why ORM product writers aren’t absolutely elated over this technology. We finally get to do away with all our stupid, ugly query engines that we all do differently and force our customers to learn. Now we simply provide an expression evaluator for LINQ and developers can use the natural syntax of their favorite .NET languages (VB9 and C#3.0 on board so far) to query our entity layers. Isn’t this a dream come true? What am I missing?
Maybe they feel depricated obsoleted 😉
If you had read my post better, or maybe I didn’t write it well enough, you’d understand that my gripe wasn’t about MS releasing cool code. I already said I like Linq a lot (see previous posting on my blog). My point was that the video had the air as if they invented O/R mapping, typed query systems and an OO view of your db. I can do that today, and I didn’t even invent it. 🙂
Also, I’m not arguing against Linq, I already said it was cool. My gripe with DLinq is that it’s the wrong choice: database specific meta-data in attributes on your domain objects isn’t scalable beyond 1 db type. Everyone in the O/R mapper business knows that and moves away from attributes. MS now presents this attribute based mapping as if it’s the best thing since sliced bread. That clearly tells me they don’t really pay attention to what happens outside their office. Watch the video yourself, the guy in the office asking the questions looked at the stuff as if he saw this technology for the very first time… OO based querying your databases!!! How cool is THAT!!!111.
…
🙂 And the comments below it. :).
@Richard: me feeling deprecated? HA! :). I just got started 🙂 See ya in Seattle next week 🙂
I think the disconnect we’re having is that you’re referring to LINQ as an ORM technology at all. It’s just not. At the end of the day LINQ itself cannot talk to anything but an in memory object. It’s only with expression trees and a specific implementation of extension methods by third parties that it can be proxied through to a backend datasource.
Even if we *were* just talking about DLINQ, you show me an ORM implementation that provides the features made possible by the core LINQ technology and I’ll eat my hat. You just can’t do projection or the natural query with static typing without the language advancements. It’s no fault of the ORM implementors, we just can’t do it… unless of course we built own compilers, but I don’t see that happening. 🙂
So do they deserve to be patting themselves on the back? Sure, even if it’s a bit premature since we won’t see this in the wild until about 2008, it’s undeniably an advancement. Maybe not DLINQ, but for the possibilities LINQ brings to the table for other ORM implementations? IMVHO, definitely.
Personally I think MS should call the technologies something other than [D|X]LINQ because it is somewhat confusing. In the end both are products built *on top of* the core LINQ technology. In fact, I’ll go a step further and say they shouldn’t be delivered as part of the core .NET framework and instead as part of something like WinFX or some other package.
I just noticed I typo’d your name as “Frand”, sorry… I fixed it!
Drew: Hear hear!
MS made a mistake with C-omega: they presented a partially baked approach to LINQ, and made the big deal about the SQL syntax integration. People fell in love with it, and it’s the only thing they see when they look at LINQ. They don’t see the expression trees, the transforms, the fact that they’re looking at a way to describe *how* to build a query, which is different from building the query, or the query itself. Habit, perhaps.
I’ll not comment on Frans’s post (except, perhaps, that it says what he apparently didn’t intend), but the comments following it all show the same lack of understanding and not a little blind worship. One would think most of the critics hadn’t bothered to read the specs — necessary, perhaps, in order to grasp the implications that just a few simple changes to the compiler (extension methods, context-sensitive treatment of lambdas, and a couple macros) allow. Of course, the only way for them to actually learn is to make an honest attempt to work *with* it.
The solution is beautiful in its simplicity. The ORM vendors should have a great time — take an XML specification, transform it into code based on LINQ, and let the compiler take care of the rest.
The samples provided show everything from simple data queries to implementing a miniature Prolog and interactive queries. Frankly, these bits could be used to create yet another computer algebra system, but that’d almost be trivial.