Harvesting some LINQ links

This post summarizes some things we've noted in tracking the reaction to XLinq in the press and blogosphere, and points to some resources we've discovered along the way.

One thing we've noted in the LINQ forum and elsewhere is that people seem to think that LINQ == DLinq, i.e. that LINQ is just some C# syntax for embedded SQL.   As we see it, however, LINQ provides a model of data access that unifies query and transformation across an extensible set of domains, including .NET collections , XML data, relational data, ADO.NET datasets, and more in the future.  Other development environments (e.g. Java) support different languages and APIs for different types of data:  JDBC for relational data, XQJ for XML databases, Groovy for XML text, and so on. With LINQ, developers use a common set of language features to query and manipulate  XML, relational data (in a DBMS or in a cache), and objects. 

It's not so much a different syntax for embedded SQL as bringing a common set of query operators to all types of data that can support the IEnumerable<T> abstraction.  It may be asking a bit much to expect the relational purists to give LINQ a fair hearing, but in reality it is doing much of what they have long advocated - making it more feasible to work with data via something very much like and very much inspired by the relational algebra.  See for example Ted Neward's piece on LINQ and similar approaches. 

One particularly powerful area of synergy between the LINQ approach and the relational algebra is exemplified by the new LINQ join operators. Anders' talk with Jon Udell focuses on this new feature in the May CTP, and many of the examples show how to use various types of join operations to simplify common XML processing tasks.  People who have seen the podcast seem to agree: "Wow!".  This isn't PowerPoint ware, this is an hour of hands-on coding and explanation by LINQ/XLinq's principal designer.

Paul Kinlan asks if XLinq has an efficient way to process very large documents without loading them into memory first.  The short answer is "no, but we're thinking about this." It would be very good to hear from others about what their needs are, what kinds of XML data they are processing, why they don't use an XML-enabled DBMS such as SQL Server 2005 to do the heavy lifting, etc.

Finally, we came across an interesting blog by Kevin Hoffman that has a number of posts on LINQ topics.  My favorite so far is his explanation of lambda expressions and expression trees, a topic I have been trying to get up the courage to tackle my series on XLinq design issues in my own blog.

Be sure to let us know about any XLinq-related sites that you find interesting or useful, and feel free to contact us either via the Contacts link or the comments section if you have questions or problems applying XLinq to real XML problems.

Mike Champion


Comments (8)

  1. Dieder says:

    My question is

    how will Linq perform in critical three tiers applications?

    And how can the queries be controlled to get the best performance?

    Can the template used for SQLMetal be changed to get other code output?

  2. XmlTeam says:

    I think this is more of a DLinq question than an XLinq question but I’ll try.  LINQ doesn’t impose a particular design pattern, e.g the way RoR imposes MVC.  There will be LINQ-enabled APIs on the client that abstract away the mid-tier, LINQ over ADO.NET DataSets, more LINQ over ADO.NET stuff that we’ll be talking more about at TechEd, and so on.  XLinq can be used on the client (including mobile Compact Framework clients), the mid-tier, and (I hope) in SQL Server .NET stored procedures.

    So, LINQ is a common programming model for data, not a model for data processing.  

    I’m not too sure about how to optimize DLinq queries for performance.  In LINQ and XLinq, some things such as in-memory joins will be more efficient than a simple hand-rolled implementation, but not as efficient as database join performed by an optimized query over a well-indexed DB. There’s no magic in at least this release of the LINQ stuff, and people will be figuring out how to tune LINQ queries for fun and profit.

    I don’t know whether SQLMetal templates can be modified in the way you suggest.  Try the LINQ forum http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=123&SiteID=1

  3. Fabrice says:

    One more link you could find interesting: http://linqinaction.net is a site dedicated to LINQ, XLINQ and DLINQ.

  4. Sam Druker (my boss’s boss’s boss, on the left) and Anders Hejlsberg talk about the May CTP of LINQ,…

  5. SqlMetal doesn’t currently support user-editable templates.

    It does, however, produce and consume XML.  You could write your own consumer to generate source for a fully-wired context in a manner more suitable to your needs.  

    That said, we are looking at other means to provide hooks, and the LINQ forums are an excellent place to make suggestions.

    re: hinting DLinq — Aside from the existing way to specify stored procedures to override CRUD operations, the out-of-the-box Sql Server provider in DLinq doesn’t have a hinting mechanism.  We do have performance targets, of course, and will support a provider model for third parties.  Third parties could, for example, provide support for hints in a way suitable to the particular server.

    However, situations requiring hand-tuned performance are, in my personal estimation, probably outside the target cases.  Over the years, I’ve seen very good performance with naive queries against well-designed databases, and I’d suggest you try it first before dismissing DLinq on the grounds of SQL performance.  I’d also suggest you go to the forums and point out where the SQL could have been better (as a general case).  DataContext.Log can be set to Console.Out if you want to view the SQL being generated.

    While we can’t necessarily address the edge cases in v1, if there’s a general performance case we’re overlooking, I’m sure it’d make a good addition to our test suite. 🙂

  6. In case you missed it, Somasegar (Microsoft’s VP of Developer Division) blogged today about some of the…

Skip to main content