Follow Up: Why Isn’t My Linq Query Working

My friend Bill gave me some good feedback on my last post where I talked about making sure you have some kind of value equality implementation on your business objects so Linq queries work the way you expect them to.  Bill informed me that anonymous types’ default implementation of Equals() is very similar to that of structs.  Two objects of an anonymous type are considered equals if all of their properties’ Equals() calls return true.  So if you can get away with using anonymous types in your Linq queries, things should work as expected.  Be careful, though, if you have properties in your anonymous types that are using reference equality.  If so, you may still see some strange behavior.

Hey, Why Isn’t My LINQ Query Working?

I wanted to share something that came up at work last week.  One of our developers was writing some LINQ and was getting some results back that seemed strange.  I thought I’d share what was going on in the hopes that someone else might benefit from it.

Let’s start by assuming you have a business object you’re working with.  In this example we’ll use something really simple, like this

public class SimpleKeyValue{
   public string Key {get; set;}
   public string Value {get; set;}
}

Now let’s say that we have a collection of those objects and we want to use some LINQ functionality to do some LINQy magic.  For example, let’s say that I have a function where I get a list of some color codes and their associated names stored in my SimpleKeyValue object.  Then, I want to see whether or not the color Red is in that list.  The code for that might look something like this.


class Program
{
    static void Main(string[] args)
    {
       var containsRed = GetRainbowColorCodes()
          .Contains(new SimpleKeyValue { Key = "Red", Value = "#FF0000" });
       Console.WriteLine(String.Format("Contains returns {0}", containsRed));
       Console.ReadLine();
    }

    private static IEnumerable<SimpleKeyValue> GetRainbowColorCodes()
    {
       return new List<SimpleKeyValue>
       {
          new SimpleKeyValue {Key = "Red", Value = "#FF0000"},
          new SimpleKeyValue {Key = "Orange", Value = "#FF8040"},
          new SimpleKeyValue {Key = "Yellow", Value = "#FFFF00"},
          new SimpleKeyValue {Key = "Green", Value = "#254117"},
          new SimpleKeyValue {Key = "Blue", Value = "#0000FF"},
          new SimpleKeyValue {Key = "Indigo", Value = "#800080"},
          new SimpleKeyValue {Key = "Violet",Value = "#8D38C9"}
       };
    }
}

The containsRed variable is going to be true, right?  Well, you might think so, but unfortunately no, it’s not.  So what’s going on here?

The issue here is that many LINQ functions, like Contains(), Except() or Intersect() are performing object comparison and call Equals() on those objects as the collection is iterated.  The thing to keep in mind is that, by default, Equals() on objects means reference equality.  That means that Equals is checking to see if the two objects being compared refer to the same memory address.  In my example above, the object in my collection of rainbow colors does not reside at the same memory location as the object being passed into the Contains method.  Because of this, the call to Equals() returns false and Contains lets you know that it didn’t find the item in the collection.

There are several ways to fix this by making sure when we are doing this kind of comparison that instead of Equals checking to see that the two objects point to the same location in memory it checks that the data contained in the objects are equivalent.  This is called Value comparison.

One simple way to do this is to make the SimpleKeyValue class a struct instead of a class.  The default behavior of Equals() for structs is to use reflection to compare the values of all the fields contained within the struct.  By simply changing the word class in our declaration of SimpleKeyValue to struct, the code now behaves as we would expect it to.

public struct SimpleKeyValue{
   public string Key {get; set;}
   public string Value {get; set;}
}

So what if you can’t change your class to a struct?  Are you just out of luck?  No, of course not.  In this case, we can override the Equals method in our SimpleKeyValue class (p.s. if you override Equals, make sure you also override GetHashCode, more about that in a later post).  If we do that, our class now looks like this.

public class SimpleKeyValue
{
    public string Key { get; set; }
    public string Value { get; set; }

    public override bool Equals(object obj)
    {
       SimpleKeyValue other = obj as SimpleKeyValue;
       if (other == null)
       {
          return false;
       }

       return (this.Key.Equals(other.Key) && this.Value.Equals(other.Value));
     } 
   
    public override int GetHashCode()
    {
       return String.Format("{0}{1}", this.Key, this.Value).GetHashCode();
    }
}

Now that we’ve done this, the Contains method uses our overridden Equals method to determine whether or not the object passed to it is in our collection.  Because we’re now explicitly telling it how to determine if these objects are equal, the LINQ statement now returns true as we expect it to.

Please note!  My implementation of GetHashCode in that class is not very good, but it was quick and easy for the purposes of this post.  If you’re doing this yourself, you probably want to read up on some better GetHashCode implementations.  Also, if this was my production code, I would probably not override Equals in this business object, but more on THAT topic in the next post.

I Love Being Lazy

As new versions of the .NET framework have been released, the common theme of many of the enhancements seems to be making the developer’s job easier. Today I’d like to talk about a new class released in the .NET 4.0 framework that does just that: Lazy<T>.

Lazy loading is a fairly common design pattern used to postpone loading a resource until it is needed.  This is not a new concept, and I’m sure code like this will look very familiar to many of you.


    private IEnumerable<Employee> employees;
    public IEnumerable<Employee> Employees
    {
        get
        {
            if (employees == null)
            {
                employees = GetEmployees();
            }
            return employees;
        }
    }
    privateIEnumerable<Employee> GetEmployees()
    {
        // Code to load employees here
    }


With the addition of the Lazy<T> class, this syntax can be simplified to the following.


private readonly Lazy<IEnumerable<Employee>> employees = 
new Lazy<IEnumerable<Employee>>(GetEmployees);

public IEnumerable<Employee> Employees
{
	get
		{
		return employees.Value;
		}
}

private static IEnumerable<Employee> GetEmployees()
{
    // Load employees here
}

When a Lazy<T> object is used, the contained object (accessed via the Value property) is initialized the first time either the Value property or the ToString() method is called.  The IsValueCreated property can be used to determine if the contained object has been initialized.

By default, when Lazy<T> objects are created, they are created to be thread safe.  In this thread safe mode (LazyThreadSafetyMode.ExecutionAndPublication), locks are used to ensure that only one thread can call the code that initializes the internal object.  This thread safety property can be overridden in the constructor.  There are two other thread safety modes: one which employs no thread safety (LazyThreadSafetyMode.None) and one where multiple threads are all allowed to run the initializer, but only the thread that completed first will be allowed to set the value (LazyThreadSafetyMode.PublicationOnly).

The constructor that I’ve most often used when I’ve used the Lazy<T> class takes a Func<T> parameter (Note:  this is the constructor used in the example above).  The function passed to the constructor is the function that will be used to initialize the contained object.  This can be as simple as the following.

private Lazy<List<string>> someStrings =
    new Lazy<List<string>>(() => new List<string>());

One important thing to keep in mind is that the Lazy<T> objects are immutable, so once you’ve created them, you can’t change them.  If needed, however, you can always reinitialize them to a new value.  So the following is not allowed.

someStrings.Value = new List<string>();

But the following is.

someStrings = new Lazy<List<string>>(() => new List<string>());

I hope this was helpful!  Happy, Lazy coding to you!

Fun with Generics – Simple sorting, pre-Linq

I recently attended the IowaCodeCamp.  I’ve found that going to these kinds of things always gets my brain buzzing with all kinds of things I want to try out.  In one talk I attended the presenter made the comment that most people have very little experience with Generics outside of using Generic Collections.  From what I’m seeing out there on the web, I would have to agree.  I’ve been playing a lot with Generic functions and classes recently and wanted to post a fun example I’ve come up with.  If this is useful to you, please feel free to grab it and reuse it.
So I wrote this because I love how easy Linq makes some things, like sorting (Ordering).  However, where I’m working, we’re not on the 3.5 Framework yet, so I can’t take advantage of the cool OrderBy function with Lambdas.  However, being able to order a collection quickly is a super nice feature.  So I wrote this function.  Hope you like it.
private Comparison GetComparison(String fieldName)
{
	List properties = new List(typeof(T).GetProperties());

	PropertyInfo property = properties.Find(

	  delegate(PropertyInfo propertyInfo)
	  {
		  return propertyInfo.Name.Equals(fieldName);
	  }

	);

	if (property != null)
	{
		return delegate(T obj1, T obj2)
		{
			IComparable value1 = (IComparable)property.GetValue(obj1, null);
			IComparable value2 = (IComparable)property.GetValue(obj2, null);
			return value1.CompareTo(value2);
		};
	}

	throw new ArgumentException(String.Format(&quot;Object {0} has no property called {1}&quot;,
		typeof(T).Name, fieldName));
}

This function can then be invoked like this:

private List GetSortedList()
{
    List people = new List
    {
        new Person{ FirstName = &quot;Jim&quot;, LastName = &quot;Smith&quot;, Address = &quot;100 C Street&quot; },
        new Person{ FirstName = &quot;Amy&quot;, LastName = &quot;Jones&quot;, Address = &quot;100 A Street&quot; },
        new Person{ FirstName = &quot;Larry&quot;, LastName = &quot;Johnson&quot;, Address = &quot;100 B Street&quot;}
    }; 

    people.Sort(GetComparison(&quot;Address&quot;));
}

I still prefer using Linq, but when I can’t, this is a nice little helper function.  Using similar techniques, your own 2.0 replacements for nice Linq functions can be created pretty easily.

Enjoy!

Getting to Lambda

An exploration of Lambda expressions for newer .NET developers.

I’ve seen quite a few articles about Lambda expressions geared toward experienced developers, but I haven’t really seen a lot that try to bridge the gaps for us “regular folks”.  Hopefully this series of blog posts will approach this topic in an easy to understand manner.

What are Lambda expressions?

Lambda expressions are a neat shorthand way of passing functionality between functions and are the logical next step from delegates.  If that doesn’t mean much to you, that’s ok.  During this series of posts, I hope to show by example that Lambda expressions are both powerful and really pretty easy to use.

The Evolution of the Lambda expression.

I know that Lambda expressions can be pretty scary and confusing the first time you see them.  I know I stared at several before I really started to understand what was going on with them.  So let’s take a step back to some familiar territory and build up to Lambda expressions from there.

Let’s say that we have a collection of strings that we want to turn to upper case.  We’ve probably all written code like this…

ArrayList stringList = new ArrayList();
stringList.Add("hello");
stringList.Add("goodbye");

ArrayList capitalizedList = new ArrayList();

foreach (String item in stringList)
{
    capitalizedList.Add(item.ToUpper());
}

The foreach command structure is something that we’re all probably pretty familiar with.  The one drawback it has is the cast that’s happening as each item is assigned from the ArrayList.  What happens if something other than a string gets added to the ArrayList?  Pure pandemonium!  Well, an exception at any rate.  Fortunately for us, .NET 2.0 introduced us to the concept of Generics (a great topic for another blog post) and more importantly for this discussion, the Generic List.  The Generic List class includes a ForEach() method that works very much like the foreach command structure but because we’re using a strongly typed Generic, we don’t have the cast to worry about.  Let’s take a look at the example from above rewritten to use the Generic List class’s ForEach() method.

List<String> stringList = new List<string>();
stringList.Add("hello");
stringList.Add("goodbye");

List<String> capitalizedList = new List<string>();
stringList.ForEach(
    delegate(String item)
    {
        capitalizedList.Add(item.ToUpper());
    }
);

So if we look closely, this really doesn’t look too different from the example using the foreach command structure.  The biggest difference is that our collection is strongly typed now because of the Generic List so we don’t have to worry about the overhead of the cast or the possibility of some type other than string sneaking into the list.  That is checked at compile time now.  If the delegate statement looks strange to you, don’t worry.  I’ll be covering that in an upcoming post.  The key is that we’re passing functionality into the ForEach() method in the form of an anonymous method.  In this case, it’s a method that takes a string as a parameter (the item parameter).

Lambda expressions are simply a shorthand way of writing these types of anonymous methods.  They use the Lambda Operator “=>” which is often read as “goes into”.  So let’s look at the exact same method from above, but we’ll use the Lambda expression shorthand.

List<String> stringList = new List<string>();
stringList.Add("hello");
stringList.Add("goodbye");

List<String> capitalizedList = new List<string>();
stringList.ForEach( item => capitalizedList.Add(item.ToUpper()) );

In this example, I’m purposely using the same names I did in the example I did above so it’s apparent how the pieces fit together.  The lambda expression can be read as “the parameter item goes into the function where…”.  As you can see, the exact same thing is happening here that was happening in the more verbose delegate version, but the code is much more compact.  Once you get used to the syntax, I think you’ll even agree that the code is much easier to read with the Lambda expression.

Ok, so admittedly, this was a very contrived example, but it was meant as an introduction.  Stay tuned and we’ll move into some more realistic examples of where and how Lambda expressions can be used.