LINQ to Objects Refresher

Hands up; how many of you have only really ever used LINQ for database access? How many of you only ever really believed it was for database access? Well it's not, it's potentially very useful in all manner of scenarios.

In this post, I'm going to go over a quick refresher about just what it is, and what you can use it for. Please note however, I'll be using the functional approach, rather than the LINQ compound statement approach; that is I'll be using:

var newList = sourceList.Select().Where(x => x.ID = 1);

form of writing code, rather than the following form:

var newlist = select from p in sourceList where ID = 1;

While the latter of the two may be easier to read, I find the former easier to work with, because it makes a logical chain of operational sequence when you read it backwards.

Let's start however with:

Just What are LINQ to Objects

As the name implies, it's regular LINQ, but used on Objects in memory, rather than on objects being called from a database as Linq to Sql does.

LINQ is largely misunderstood beyond this though, and just as it can do some very clever filtering and searching with objects from a database, if can perform just about all the same operations on collections held in your applications memory space.

Many of you will have used things like:

List<int> myListOfIntegers;

or

IEnumerable<string> myEnumerableListOfStrings;

In your .NET applications.  Anywhere you use lists and other collections like this, you can iterate over them, sort them and re-project them on the fly using LINQ. I'll not be delving right down into the absolute depths in this post as we just don't have enough space, but I will show you some of the basics that you'll end up using quite a lot.

Let's start with some simple filtering and searching. Let’s imagine you had the following data specified in your application:

List<Employee> myEmployees = new List<Employee>

{

  new Employee{ FirstName = "Bill", SecondName = "Cosby", Id = 1, Status = "Permanent" },

  new Employee{ FirstName = "Freddy", SecondName = "Kruger", Id = 2, Status = "Temporary" },

  new Employee{ FirstName = "Cindy", SecondName = "Sunshine", Id = 3, Status = "Permanent" },

  new Employee{ FirstName = "The", SecondName = "Stig", Id = 4, Status = "Temporary" }

}

Using the pre LINQ methodology, if you wanted all the entries that had a status of "Permanent", you might do something like:

List<Employee> results = new
List<Employee>();

foreach(var employee in myEmployees)

{

  if(employee.Status == "Permanent")

  {

    results.Add(employee);

  }

}

While this is still nice and compact, and easy to read, using pure LINQ to Objects you can achieve the same in one line, like so:

List<Employee> results = myEmployees.Where(x => x.Status == "Permanent").ToList();

The new list will include only the entries from the first that match the criteria in the Where operator.

The strange operator you see in the where clause is called a 'Lambda', and yes I can hear the next question straight away.

What's a Lambda?

Ok, let me get this one out of the way, immediately.

A lambda in C# is not in any way related to Lambda Calculus, or to Haskel portable lambdas or anything like that, it is simply a term that the C# engineering team decided to use for what is essentially a self closing, self executing block of code.

Lambdas are not some magical concept that the .NET development team dreamt up to make LINQ stand out from the crowd, and to be honest, you could just call them Anonymous functions or closures and get by with them perfectly well. At the end of the day a lambda is simply a block of code that can be passed as a parameter in a function definition.

Taking our where example above, we could change it to read:

List<Employee> results = myEmployees.Where(employee => employee.Status == "Permanent").ToList();

If you now compare that to the example using the for each loop, you can see that all we are really doing is passing in the inner code that was present in the if clause embedded inside the loop.

The 'employee =>' part simply tells the 'Where' function that for every element in the list I passed to you, you need to assign to 'employee' a copy of that current element, as we loop through them all.

Following from that, we then just make a statement that asks where to check a given property on the copy, and where then decides if it should or should not return it.

Filtering on a specific property is not all we can do; how about ordering things in a given sequence:

List<Employee> results = myEmployees.OrderByDescending(x => x.Id).ToList();

Will return our entire employees list, in reverse order with the first record starting at id = 4 and decreasing to id = 1.

What about if you only wanted the first permanent employee, with the lowest id (i.e.: they've been in the system the longest)? That's simple also; you just need to combine different operators:

Employee result = myEmployees.OrderBy(x => x.Id).Where(x => x.Status == "Permanent").First();

The above code will give you exactly one employee.

If you use 'FirstOrDefault' rather than 'First' and NO employees exist in the list who have a Status of Permanent, then you'll get a 'null' result rather than an Exception of 'sequence matches no elements' , which means you can quietly handle the fact that no entries exist and take some other course of action.

You can also perform Aggregates on your collection; let's find out what all our ID's add up to:

int result = myEmployees.Sum(x => x.Id);

Not very useful I know, but imagine if that was a salary level or age range.  How about an Average?

double result = myEmployees.Average(x => x.Id);

Once again, imagine if the value we were looking at contained a more useful value.

You can even use LINQ to Objects to 'Page' your data:

List<employee> pagedData = myEmployees.Skip(1).Take(2).ToList();

The above code will return a list that starts at the second record in the collection, and takes only 2 records, which in our example would be "Freddy" & "Cindy".

You can also use 'SkipWhile' and 'TakeWhile' which will continue executing as long as a condition is true.  If for example you had a list of to-do items, you could say:

var firstBatchOfCompleteTasks = myTasks.SkipWhile(x => x.Status == "Done").TakeWhile(x => x.Status == "Not Done");

This would keep skipping until it found the first object that did not match the status in the Lambda, and then continue taking until the status in Lambda 2 returned a false condition.

There are dozens of operators and with a simple little command line program such as this:

using System;
using System.Collections.Generic;
using System.Linq;
 
namespace dnnutsandbolts
{
  static class Program
  {
    static void Main()
    {
      List<Employee> myEmployees = new List<Employee>
      {
        new Employee {FirstName = "Bill", SecondName = "Cosby", Id = 1, Status = "Permanent"},
        new Employee {FirstName = "Freddy", SecondName = "Kruger", Id = 2, Status = "Temporary"},
        new Employee {FirstName = "Cindy", SecondName = "Sunshine", Id = 3, Status = "Permanent"},
        new Employee {FirstName = "The", SecondName = "Stig", Id = 4, Status = "Temporary"}
      };
      var result = myEmployees.<Experiment with the Linq Calls here>
    }
  }
 
  public class Employee
  {
    public string FirstName { get; set; }
    public string SecondName { get; set; }
    public int Id { get; set; }
    public string Status { get; set; }
  }
}

The intellisense built in to Visual Studio will list them all for you and show you the type of Lambda they take.

Just about anything you can think about doing in an SQL Database, can be performed equally well on an in-memory collection, and if you start to use PLINQ rather than just normal LINQ, you get multi CPU aware operations virtually for free and without having to write your own multi threaded code to handle it.

Feel free to let me know what you'd like to see in this column, or if you have any burning questions you'd like answered seek me out on Twitter as @shawty_ds or in the Linked.NET (Lidnug) users group on Linked-In that I help run. Code happy.



Related Articles

Comments

  • Debugging Linq?

    Posted by Daniela on 08/21/2014 05:31am

    I must admit I am from the old school, much before Linq. I was really skeptical at the beginning. One by one, my reserves were gone. One single thing I still have against Linq: you cannot debug it! Is it a way to do it and I don't know it? Thanks!

    • RE: Debugging Linq?

      Posted by Peter Shaw on 09/26/2014 07:33am

      Hi Daniela, Yes your absolutely correct. That has to be the number one grumble I hear from other Dev's in the industry these days. Recent versions of Visual Studio are getting better, and while there's still no direct debugging, there are improvements that do make things easier to work with. I have to admit though, I actually cheat when it comes to debugging, well at least with Linq enumerations and loops any way. What I do is I construct the query using a standard for-each loop, then I step through that to make sure any data manipulation I'm doing is as correct as can be. Then I use Re-sharper to turn the loop into a compound Linq Statement once I'm happy that things are working. It's not a perfect way, but it get's you 80% of the issues you may encounter.

      Reply
    Reply
  • Ccna, cisco ccna, cisco networking and cisco material

    Posted by cisco material on 07/31/2014 12:01am

    Thanks, really helpful one, hope of getting more in future.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: December 11, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Market pressures to move more quickly and develop innovative applications are forcing organizations to rethink how they develop and release applications. The combination of public clouds and physical back-end infrastructures are a means to get applications out faster. However, these hybrid solutions complicate DevOps adoption, with application delivery pipelines that span across complex hybrid cloud and non-cloud environments. Check out this …

  • With the average hard drive now averaging one terabyte in size, the fallout from the explosion of user-created data has become an overwhelming volume of potential evidence that law-enforcement and corporate investigators spend countless hours examining. Join Us and SANS' Rob Lee for our 45-minute webinar, A Triage and Collection Strategy for Time-Sensitive Investigations, will demonstrate how to: Identify the folders and files that often contain key insights Reduce the time spent sifting through content by …

Most Popular Programming Stories

More for Developers

RSS Feeds