LINQ Exchange

As part of our goal to make Linq Exchange a more social website, I’m inviting you, the friendly reader, to submit your LINQ or Lambda Expression article. Your article will appear on the Linq Exchange website within one week of submission (pending review and approval).

You may include one link back to your blog or website (including graphic logo).

Submission Rules:

1. Your article must be about LINQ or Lambda Expressions
2. Your article must be at least 350 words in length
3. You must include at least one code example
4. You may provide one link and graphic logo to your website or blog. This link will be placed at the end of your article.
5. You may submit your article as a PDF, Word doc, HTML file, or plain text (HTML is preferred, please).
6. Your article will appear on the Linq Exchange website withing seven days of submission, pending review and approval by the Linq Exchange team.

Submit your articles to articles@linqexchange.com

Lambda expressions are a powerful tool to writing quick, concise code. They can be used in numerous situations, most notably in conjuction with LINQ statements.

A lambda expression is an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.

All lambda expressions use the lambda operator =>, which is read as “goes to”. The left side of the lambda operator specifies the input parameters (if any) and the right side holds the expression or statement block. The lambda expression x => y * z is read “x goes to y times z.”

Here’s how a typical LINQ query looks like without using lambda expressions:

var query = from m in db.PersonalMessages
where m.ConversationID_FK == ConversationID
select m;

Okay, not bad. It looks like a SQL query in reverse (i.e. you start off with “from” and end with “select”). This is so that intellisense can help you out—if you started with select, it would have on idea where you were going with the query.

we are selecting PersonalMessages where the ConversationID is equal to some value passed into the method. The query itself is kinda verbose, and I like to keep my code short and sweet, so how do I re-write this using lambda expressions? Here is the code, and then we’ll break it down:

var query = db.PersonalMessages
.Where(m => m.ConversationID_FK == ConversationID);

We got rid of “select’”, “from” and “in”, etc. Cleaned it up quite a bit. What all is happening though? Basically it’s written out like:

My Query = Get Personal Messages from my data context Where the ConversationID is equal to this #

In other words, it reads exactly like it does in the first written out query, but it’s done faster. The where statement is like a mini-method. You’re defining some variable M (you can use any letter, I always use m for the sake of convention in my code) and then in this case you’re giving m some condition to work with.

You’re basically saying, define m real quick (m=>) as a stand-in for PersonalMessage. Then only return PersonalMessages where m’s ConversationID is equal to some value. Again, just to drill in the point, it’s like typing in:

var query = DataContext.PersonalMessages.Where(PersonalMessage=>PresonalMessage.ConvoID = ConvoID);

Now I want to get even faster with my method calling. Instead of defining a query, then returning it, or doing other things to it, I can easily chain things to it. Lets say I want to return a List of personal messages. I can now do:

List<PersonalMessage> myPersonalMessages = db.PersonalMessages
.Where(m => m.ConversationID_FK == ConversationID)
.ToList();

Very easy. I can go even further, now, all with the ease of dot notation. Lets say I want to order it by the date the personal message was created. No problem, I can throw in an .OrderBy:

List<PersonalMessage> myPersonalMessages = db.PersonalMessages
.Where(m => m.ConversationID_FK == ConversationID)
.OrderBy(m=>m.DateCreated)
.ToList();

Again, I’m creating a little “mini-method” that is passing in the personal message as m, and saying to order it by the date it was created. The possibilities are limitless!

When using Linq to objects, you will quickly feel the need to pass some parameters from a method to another but it’s not so easy because each Linq method is not calling the following one. In a Linq sequence, each method is using the result computed by the previous one. So, local contexts are not visible from one method to another.
The compiler is using two technical different ways to let parameters go out of a method.

As an example, let’s first see how the .SelectMany() method is working.

This very little example shows that s1 and s2 are both accessible in the select. It’s nice, but how does this work ?
You must know that the ‘from’ statement of the Linq sugar syntax does not match any existing Linq method. Let’s see how we would have written this using the classical C# syntax.

Let’s focus on the SelectMany parameter:

SelectMany(Func<TSource, IEnumerable<TResult>> selector).

The method must return an IEnumerable<TResult>. In our example, we get it using values2.Select(). We are now touching the interesting point. The parameter of the .Select() is also a lambda “s2 => s1 + s2”. In Linq to object a lamda generates an anonymous method and anonymous methods can access their host scope. Here, s1 is visible inside values2.Select().

So the first solution to share parameters between methods is to nest them

like “.SelectMany(s => s.Select(s2 =>’s is accesible here’ ))”

instead of creating a sequence “source.Skip(‘scope1’).Take(‘scope2’)”

Now what if we would like to share a parameter between two following methods like Skip() and Take() ?

Let’s see how the “let” keyword works.

In the next example, I will start from a list of numbers stored as strings.
I would like to get only numbers greater than 10 and order them by their value but keeping the result as an enumeration of string.

We can write it quickly this way:

This works fine but we all notice the ugly “Convert.ToInt32(s)” used twice on the same value. Thanks to the “let” keyword we can create a new parameter that will be accessible in all the query.

We can see that the “let” keyword solves this problem extremely easily. But once again the sugar syntax of Linq is really magic. As we always want to know the secrets of magic tricks, let’s try to get the same result without using the “let” keyword and we will find out what the C# compiler is really doing.

Let’s start by decomposing all the steps using the regular C# syntax.

I have chosen to decompose this way to show that the only place to share something between the Where() and the OrderBy() is the result.

Now we have to make a new parameter travel across the sequence in addition to the current result. The idea is to create a new type to group the current result and the new value. To achieve this easily we can just use a anonymous type.

We can of course write this in a single Linq query

which is the exact equivalent of what is compiled when using the ‘let’ keyword

var q =
from s in values
let i = Convert.ToInt32(s)
where i > 10
orderby i
select s;

Of course the Linq syntax is extremely short but it’s always nice to know what’s happening behind the scene.

I hope this sample can also help you to solve some other problems when playing with Linq.

Can you guess what the output of the following program is?

using System;
using System.Collections.Generic;

namespace Lambda
{
    class Program
    {
        static void Main(string[] args)
        {
            var strings = new[] {"a", "b", "c"};
            var actions = CreateActions(strings);
            actions.ForEach(f => f());
        }

        private static List CreateActions(IEnumerable strings)
        {
            var actions = new List();

            foreach (var s in strings)
                actions.Add( () => Console.WriteLine(s) );

            return actions;
        }
    }
}

I expected to see all three strings (a, b and c), but instead I got this:

While analyzing the IL code with Reflector I learned a thing or two about lambdas in C#.
When a lambda is encountered by the compiler, it generates a class which has a field for each local variable used by the lambda. In this case, the generated class would look like this in C#:

private sealed class <>c_DisplayClass3
{
    public string s;
    public void 
b_0()
    { Console.WriteLine(this.s); }
}

Of course, the above is not valid C# due to invalid characters in identifiers, but is pretty much what is produced in the IL.
So far so good – no real surprises here. However, look at this code which is my translation from IL to C# of the CreateActions method:

private static List CreateActions(IEnumerable strings)
{
    List actions = new List();
    using (IEnumerator enumerator = strings.GetEnumerator())
    {
        // Note 1: The lambda is created outside of the loop
        <>c_DisplayClass3 lambda = new <>c_DisplayClass3();

        string s;
        while (enumerator.MoveNext())
        {
            s = enumerator.Current;

            // Note 2: The instance field is reassigned each time
            lambda.s = s;
            actions.Add(lambda);
        }
    }
    return actions;
}

The reason for the strange output is clear now – the compiler did not create a lambda object in each iteration but rather reused the existing one each time. After the loop, all items in the actions list are actually the same instance and their s field is the last element of the collection. Apparently, C# compiler creates a lambda instance immediately before the local variable it uses. So, in order to force it to create a new lambda for each iteration, we need to introduce a new local variable in the loop:

private static List CreateActions(IEnumerable strings)
{
    var actions = new List();

    foreach (var s in strings)
    {
        // This variable will be used in the lambda
        var lambda_param = s;
        actions.Add( () => Console.WriteLine(lambda_param) );
    }

    return actions;
}

With this modification the program now produces this output:

This video, courtesy of Microsoft’s ASP.NET video series, provides an example of using LINQ to SQL to execute arbitrary SQL against a database.

This video, courtesy of Microsoft’s ASP.NET video series, provides an example of using LINQ to SQL and stored procedures to update a table.

This video, courtesy of Microsoft’s ASP.NET video series, provides an example of using LINQ to SQL with stored procedures.

This video, courtesy of Microsoft’s ASP.NET video series, provides an example of creating a custom LINQ to SQL LinqDataSource.

This video, courtesy of Microsoft’s ASP.NET video series, provides an example of using the LINQ to SQL LinqDataSource.