Joining, Grouping and GroupJoining in LINQ

As you may already know I really, really like LINQ. One day I’ll probably join together all my posts about this incredible featureand release pretty neat compendium/one-oh-one about this great feature. But while I’m not sitting and joining every post from this blog that have word “LINQ” in it into one, big pile, let’s talk a bit about joining and grouping collections in LINQ.

Arranging collections by some sort of key or other common value with LINQ is easy task. Just think about basic SQL joins with foreign keys, ids and one-to-one or one-to-many relationships in databases. It’s simple, basic database stuff. And similiar things are possible while using LINQ.

However we may encounter the same problem that I’ve mentioned few weeks ago in my post about Aggregate method – Joins, GroupJoins and even some overloads of GroupBy looks complicated. You probably know how they work, but if you’ve never used them before, just looking at method definitions with generic Funcs can make you think “oh crap, I’ll just use simple for loop instead”. I really hope, that after this post everything will be clear and you will see, that those methods are as simple as basic SQL join.

I know that reading about complicated, generic methos with many parameters related to each other are not as readable as I would want to. Feel free to download code samples for this post from my github.

Basic GroupBy

Let’s do a little warmup, boring paragraph about simplest grouping method in LINQ – GroupBy. It will be most basic usage of this method, and since it have some more powerfull overloads I’ll get back to them in a while – but for now simple things first. So if you already know this method, you can just jump to section dedicated for Joins, since I’ll cover some rather basic stuff in next few paragraphs.

Imagine a shopping list, something with product name and category. Something like that:

During your shopping run (or supply run in case of some kind of apocalypse scenario) you most certainly will need to organize your list by categories to make sure you visit only necessary stores and buy all items in one visit. Perfect method for this is GroupBy. So let’s use it and print some results:

Result in console should look just like that:

What happened? We’ve just grouped every item by it’s Type. Variable groupedList is of type IEnumerable<IGrouping<string, product>>, you can look closer at the implementation of IGrouping in .NET here. Point is, IGrouping has a key, which could be used to access all matching values. In simpler words it is collection where every item you’ve had at beginning suddenly have a key. It’s NOT, a dictionary but can easily be allocated into one like that.

Or you could just filter groups with Where and Select results:

Take a closer look at IGrouping (i.e. group in example above). You can access it’s Key with group.Key property or you could just use ToList, ToArray, AsEnumerable or just iterate through it, group (or rather it’s type – IGrouping) implements IEnumerable and contains every item with equal key (and yes, you can use custom Comparers in GroupBy overloads).

Let’s leave GroupBy for a while, I’ll get back to it’s overloads soon, for now lets jump into fun stuff – joining things together.

Join

Let’s change our context a bit and imagine you want to import all of your contacts from your old phone and your email client, then you want to synchronize them together into some new, fancy system. You’ll have two collections of contact data that would look like that:

We have our simple model, so let’s try to synchronize our data. Only things that we can use as keys are Name properties, and while in real world it wouldn’t be best idea (how many Johns you know?), for sake of this example let’s agree Name will be our key and we will join two collections by this property.

Since two collections contains two different types of objects we can’t use GroupBy (well, not directly, we could make two dictionaries with names as keys and access data this way, but I would not recommend this solution). If this were SQL tables everything would be much simpler right? Simple as that:

Sadly our data isn’t SQL but you may remember LINQ have query syntax which very closely ressembles SQL queries. Let’s stick to that for a while because you can do Joins in LINQ and they’re much simpler and easier to understand in query syntax. And to join our collections and project them to AddressBookItem and print our results you could use this code.

Our console should have those printed now:

So everything is great. Well, almost everything. I’ll not explain query syntax from above example right now because while it have it’s uses I don’t really like it. Instead let’s write exact same query but in normal, chained LINQ. I’ll use named method parameters as well as more explicit naming convention in lambdas in further examples, because explaining something is much easier this way. Consider using those in your code for added clarity in more complicated events.

We passed our two collections to our Join method. First one is phoneBook and is being extended by LINQ method (this parameter is named “outer” ). In parameters we pass our second collection as “inner” parameter. Then we pass two delegates in succession – outer and inner key selectors, those are our keys and if they’re equal our items will be joined together. Last parameter is “resultSelector”, delegate with two parameters which are two joined items, in succession – outer and inner one.

Above example is not so complicated, but is it valid? Let’s see printed results.

Ooops! Something went wrong and I’ve forgotten about case sensitivity. My two imported contact lists have same names but other cases. Please take a note, that query syntax didn’t noticed case difference and items that were not joined were just ignored without throwing any exceptions. Now let’s use Join overload with “comparer” parameter and this should do the trick.

I don’t really want to paste console results but believe me, it worked like a charm, everything is fine. Our two lists were successfully Joined and lived happily ever after. Well… until you reminded yourself that you had more complex contact list with email somewhere and you want to synchronize it too.

GroupJoin

For GroupJoin we’ll use some of data from previus examples and some new ones. Our new contact items and a bit more complex model looks like that.

Let’s try to use Join, just as in previous examples. After all, it shouldn’t be complicated.

And what happened? When we’ll print results to console we’ll see this:

It’s not exactly what we were trying to achieve. Reason for that is simple – Join is equivalent of SQL Inner Join and as such should be used for joining single results. Our new complexMailBook item requires something that behaves like SQL Outer Join and in LINQ this behavior is represented by GroupJoin method that should be used for matching single objects to collection of other objects (just like in 1:* database relationship). So let’s use right tool for the job now.

As you can see GroupJoin looks almost the same as Join, main difference is second parameter in resultSelector lambda, instead of single object it is collection of matching objects, aparts from that there are no important differences in invoking GroupJoin. And this allowed us to get results that we’ve wanted:

I hope LINQ Join and GroupJoin don’t hide any secrets from you now and you understand them clearly now. As we started with little warmup with GroupBy method let’s move to some cooldown with some of it’s more fun (less boring) overloads.

Advanced GroupBy

GroupBy have 8 overloads (if you count only IEnumerable extensions), but don’t worry, they can be matched (Joined 😉 ) in pairs where one have comparer parameter and one does not. Since we’ve already started with basic GroupBy they are only 3 left. Let’s use our old collections and models for this sections.

This one is simple and it introduces element selector parameter. It allows us to pass selector delegate that will indicate element which will be stored in our IGrouping or use method that will return desired value. Basic example for this is:

And in console we’ll get those results:

Next GroupBy overload introduces result selector which allows us to project each of our groups to new, chosen objects. There are two parameters for this selector and those are: key and grouped collection (type of IEnumerable). This delegate can be really fun with Aggregate method to chose “best” object in group. But in our simple context it could be used like that.

Which will print this in our console:

We could achieve exactly same result with last GroupBy overload that takes both result and element selector, and since we need to extract all emails from our groups we should use this:

Summary

Joins are fun and pretty easy if you take a while and try to understand how they work, and how their parameters relate to each other. Joins and GroupJoins are not commonly used methods in LINQ but they could be useful and in right place they can be quite powerfull to. They have also one big, great even, virtue – they can be used with LINQ to Entities (excluding complex projections and custom comparers), Parallel LINQ and/or others, and if used correctly they can generate i.e. better SQL query than clumsy LINQ chains assembled by someone who knows just Where, Select and ToList LINQ methods (send him or her link to my blog in that case 😉 ).

I hope you have learned something new and this long post made you a litle bit smarter. If you don’t want to miss my next posts you can follow my Facebook fanpage or Twitter. This way you’ll never miss my new posts. See you soon!