Pros & cons between LINQ and traditional collection based approaches

Question

Being relatively new to the .net game, I was wondering, has anyone had any experience of the pros / cons between the use of LINQ and what could be considered more traditional methods working with lists / collections?

For a specific example of a project I'm working on : a list of unique id / name pairs are being retrieved from a remote web-service.

• this list will change infrequently (once per day),
• will be read-only from the point of view of the application where it is being used
• will be stored at the application level for all requests to access

Given those points, I plan to store the returned values at the application level in a singleton class.

My initial approach was to iterate through the list returned from the remote service and store it in a NameValueCollection in a singleton class, with methods to retrieve from the collection based on an id:

sugarsoap soapService = new sugarsoap();
branch_summary[] branchList = soapService.getBranches();

foreach (branch_summary aBranch in branchList)
{
    branchNameList.Add(aBranch.id, aBranch.name);
}

The alternative using LINQ is to simply add a method that works on the list directly once it has been retrieved:

public string branchName (string branchId) 
{
    //branchList populated in the constructor
    branch_summary bs = from b in branchList where b.id == branchId select b;
    return branch_summary.name;
}

Is either better than the other - is there a third way? I'm open to all answers, for both approaches and both in terms of solutions that offer elegance, and those which benefit performance.

Answer 1

I'm not sure a singleton class is absolutely necessary, do you absolutely need global access at all times? Is the list large?

I assume you will have a refresh method on the singleton class for when the properties need to change and also that you have some way of notifying the singleton to update when the list changes.

Both solutions are viable. I think LINQ will populate the collection faster in the constructor (but not noticeably faster). Traditional collection based approaches are fine. Personally, I would choose the LINQ version if only because it is new tech and I like to use it. Assuming your deployment environment has .NET 3.5...

Do you have a method on your webservice for getting branches by Id? That would be the third option if the branch info is needed infrequently.

Answer 2

i dont think the linq you wrote would compile, it'd have to be

public string branchName (string branchId) 
{
    //branchList populated in the constructor
    branch_summary bs = (from b in branchList where b.id == branchId select b).FirstOrDefault();
    return branch_summary == null ? null : branch_summary.name;
}

note the .FirstsOrDefault()

I'd rather use LINQ for the reason that it can be used in other places, for writing more complex filters on your data. I also think it's easier to read than NameValueCollection alternative.

that's my $0.02

Answer 3

@john-boker - yes of course you're correct, as the LINQ would return a list (even if there were no matching items or there was only one)

@robboblob - the singleton would contain a method to refresh the list that could be called if required, and may even run auto-magically at set intervals. The summary list would be used extensively throughout the site hence my desire to cache it - a round trip of even a few hundred ms for each request can become quite noticeable. Whilst the service does also expose a method to return a single branch by id, it returns a lot more data (20 or so attributes), which would only really be used on perhaps one page.

Answer 4

In general, your simple one-line for/foreach loop will be faster than using Linq. Also, Linq doesn't [always] offer significant readability improvements in this case. Here is the general rule I code by:

If the algorithm is simple enough to write and maintain without Linq, and you don't need delayed evaluation, and Linq doesn't offer sufficient maintainability improvements, then don't use it. However, there are times where Linq immensely improves the readability and correctness of your code, as shown in two examples I posted here and here.