LINQ to Objects Reality Check

The following post is actually a translation of a post I wrote last year for our internal company blog. It’s already gained some moss, so to speak (LINQ is released; isn’t there some new technology to blog about? 😉 ), but it may still serve as motivation for those who have successfully avoided the LINQ hype so far. And I kind of need it as introduction to some other posts I have in mind.

Here we go…

To me, LINQ seemed to be quite interesting, but until recently it was exactly that: a semblance — and one that has to be proved. I didn’t want another bunch of test code showing the exact problems that LINQ was built to solve and LINQ (surprise!) solving those problems. I wanted to see how LINQ fared in a real world scenario, i.e. based on existing code not built with LINQ in mind.

I have a little prototype application at my disposal. Not exactly a productive application, but near enough for my purpose. It’s a simple 3tier web application, as outlined in an earlier post.

My experiment took three steps:

1. Migration to VS2008 und .NET 3.5
2. Employment of LINQ to Objects
3. Employment of LINQ to SQL

Here are my experiences — the LINQ to Objects part in this post, the LINQ to SQL part in the next one. Valuations are purely subjective 😉 …

The migration ran smoothly enough, unit test assemblies had to migrated manually and code analysis spit out a lot of new warnings (which may be an issue in bigger projects and if you like “warnings as errors”). Otherwise the application ran without problem.

Employment of LINQ to Objects

LINQ to Objects is only a using statement away. All you have to do is adding the following line (and the respective assembly reference, if not done already):

using System.Linq;

Afterwards I scanned the existing code for rewrite candidates. You don’t need to understand the gory details of the following samples, the important thing is the relation between the non-LINQ and the LINQ versions. The relevant parts of the samples are in bold.

1. Example: A code fragment that reads all accounts of a customer and calculates the balance.

Customer c= ….
IList<Account> al = AccountTable.GetAccounts(c.Id);

c.TotalBalance = 0;
foreach (Account a in al)
     c.TotalBalance += a.Balance;

The rewrite with LINQ:

Customer c= …
IList<Account> al = AccountTable.GetAccounts(c.Id);

c.TotalBalance = al.Sum(a => a.Balance);

Effect: Calculating the sum is down from 3 lines of code to one line of code — and quite a bit more readable as well.

2. Example: Find a sub account in a sub account list.

IList<Account> list1 = AccountTable.GetAccounts(c.Id);

Account a= null;
foreach (Account a1 in list1)
{
     if (a1.SubAccount == subAccount)
     {
         a = a1;
         break;
     }
}

Another “classical” version could have been provided via an anonymous delegate, though only available with the class List<>, not the interface IList<>:

IList<Account> list1 = AccountTable.GetAccounts(c.Id);

List<Account> list2 = list1 as List<Account>;
a = list2.Find(
     delegate(Account test)
     {
         return (test.SubAccount == subAccount);
     });

And the LINQ version:

IList<Account> list1 = AccountTable.GetAccounts(c.Id);

Account a = list1.First(test => (test.SubAccount == subAccount));

The effect: LOC down from 9 (6 with delegate) to 1. And more readable. And applicable on the interface (rather than the List<> class).

Conclusion:

In the cases shown above, LINQ to Object provides way more efficient code, less code, better readable code. The cases were all related to list operations. And this is by no means tied in any way to database operations, i.e. any code may profit from this. On the other hand, I didn’t find any other use cases beside list operations in the existing code.

At a closer look only a subset of the LINQ features were involved: Extension methods, lambdas, and the System.Linq library. This is not an issue, just stating a fact. It’s not that the query syntax and other features aren’t available without database, it’s just that I didn’t need them.

End of part 1, the short and easy on, actually. But very convincing so far. The next post will look into LINQ to SQL.

That’s all for now folks,
AJ.NET

Advertisement