C# in Depth

Summary31311.7 SummaryIn this chapter, we’ve looked at how LINQ to Objects and C# 3 interact, focusing onthe way that query expressions are first translated into code that doesn’t involve queryexpressions, then compiled in the usual way. We’ve seen how all query expressionsform a series of sequences, applying a transformation of some description at eachstep. In many cases these sequences are evaluated using deferred execution, fetchingdata only when it is first required.Compared with all the other features of C# 3, query expressions look somewhatalien—more like SQL than the C# we’re used to. One of the reasons they look so oddis that they’re declarative instead of imperative—a query talks about the features of theend result rather than the exact steps required to achieve it. This goes hand in handwith a more functional way of thinking. It can take a while to click, and it’s certainlynot suitable for every situation, but where declarative syntax is appropriate it can vastlyimprove readability, as well as making code easier to test and also easier to parallelize.Don’t be fooled into thinking that LINQ should only be used with databases: plainin-memory manipulation of collections is common, and as we’ve seen it’s supportedvery well by query expressions and the extension methods in Enumerable.In a very real sense, you’ve seen all the new features of C# 3 now! Although wehaven’t looked at any other LINQ providers yet, we now have a clearer understandingof what the compiler will do for us when we ask it to handle XML and SQL. The compileritself doesn’t know the difference between LINQ to Objects, LINQ to SQL, or anyof the other providers: it just follows the same rules blindly. In the next chapter we’llsee how these rules form the final piece of the LINQ jigsaw puzzle when they convertlambda expressions into the expression trees so that the various clauses of queryexpressions can be executed on different platforms.Licensed to Rhona Hadida