Let me say it again: Linq==cool

For the people who misunderstood me in my last posting: I really like Linq as a general purpose system to offer a single interface for accessing enumerable data structures.

My point in my previous posting wasn't to rant about Linq, as I truly like it, my point was that the video gave me the idea as if they believed they had invented something like O/R mapping, an OO overview of your relational model and a compile-time checked query system. I can do that today, so that's nothing unique. .

Though, at the moment, every O/R mapper vendor uses his own query system, his own system to map objects, his own system to track changes, his own system to interact with other systems, build in validation, workflow, do serialization/remoting etc. With Linq (that's not: DLinq, but Linq), this can be made more generic: the user can now work more transparent with the underlying engine, from whatever vendor.

So Linq solves an actual problem. Now, DLinq on the other hand is a different story. DLinq might seem it will make things easier, but it carries along some mistakes already known for years by the O/R mapper vendors. I therefore see DLinq as an example implementation, how the Linq system works in practise, how you can extend it into a given direction.

Personally, I'm not that worried about DLinq, I just find it a missed chance for MS to create something great. I mean, instead of solving other problems in the OO world, like cross-appdomain object awareness so server-farm wide object caches can be created so you really can have safe object caching outside the database, it comes with an already surpassed O/R mapper lookalike (DLinq, not Linq). I also wonder why MS comes with DLinq at all, because are they now suddenly convinced everyone should drop the Dataset and move on to an O/R mapping world? As Anders said in the video, it's a future version of ADO.NET, but what about the hardcore table/raw sql focussing crowd? I.o.w.: current ADO.NET building blocks have to stay, you can't drop these out, as you'll then abandone that crowd of people, currently using stored procs and datasets/readers.

Don't think lightly about this: DLinq from MS is a huge paradigm-shift. From service oriented, based on messages and anonymous datasets to domain oriented, with typed domain objects. We'll see how it evolves. I only hope Linq isn't compromised to make DLinq work better, but kept as generic as it is now, so 3rd party vendors can actually use it as our next-gen query language, which is a big benefit for our customers/users.


  • That is very well said. I doubt anyone already in the O/R mapper business ignores the benefits of LINQ - it is just, as you said, that DLINQ is pretty much the worst possible thing MS could have done for implementation. Plus it DOES provide a very nice chaos (!) of query systems for C# 3.0, with a lot of the current technology just being abandoned.

  • Frans, great post. They are going to have to document the hell out of the query language syntax. I was up and running using LLBLGen Pro's API pretty quick, while I'm still trying to get my arms around how to perform non-trivial queries with Linq syntax (Dlinq). For example, create a predicate expression in LLBLGen Pro to basically do a select customerID, CompanyName, CountOrders grouping by customerID...then do the same thing using Dlinq...then compare the SQL syntax using SQL Profiler. I agree, the concept of DLinq cool (maybe not the implementation), but it is of course unproven. :-)

  • Great summary -- and I totally agree.

  • Frans,

    Way to clarify! Now I think we're all on the same page. :)



  • Right ;)

    Some people don't understand what are Linq compared to SQO, DLinq and XLinq where Linq is on top of.

Comments have been disabled for this content.