Pros and cons between LINQ and traditional collection-based approaches

Question

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

For a specific example of the project I'm working on: the list of remote web services is retrieved from the list of unique id / name pairs.

• this list will change infrequently (once a day),
• will be read-only in terms of the application in which it is used.
• will be stored at the application level for all requests to access

Given these points, I plan to keep the return values ​​at the application level in a singleton class.

My initial approach was to iterate over the list returned from the remote service and store it in NameValueCollection in a singleton class, with methods for retrieving from the collection based on identifier:

sugarsoap soapService = new sugarsoap(); branch_summary[] branchList = soapService.getBranches(); foreach (branch_summary aBranch in branchList) { branchNameList.Add(aBranch.id, aBranch.name); } 

An alternative using LINQ is to simply add a method that works in the list immediately after receiving it:

 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; } 

Better than the other - is there a third way? I am open to all the answers, both for both approaches, and for solutions that offer elegance, and those that benefit productivity.

Answer 1

I don't think the linq you wrote will compile, it should 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; } 

pay attention to .FirstsOrDefault ()

I would rather use LINQ for the reason that it can be used elsewhere to write more complex filters for your data. I also find this easier to read than an alternative to NameValueCollection.

what's mine $ 0.02

Answer 2

In general, your simple single-line for / foreach loop will be faster than using Linq. In addition, Linq does not always offer improved reading capabilities in this case. Here is the general rule that I encode:

If the algorithm is simple enough to write and maintain without Linq, and you do not need a deferred evaluation, and Linq does not offer sufficient improvements in maintainability, then do not use it. However, there are times when Linq greatly improves the readability and correctness of your code, as shown in the two examples. I posted here and here .

Answer 3

I'm not sure if a single class is absolutely necessary, do you really need global access? Is the list large?

I assume that you will have an update method for a singleton class, when the properties should change, and you also have a way to notify the singleton to update when the list changes.

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

Do you have a method in your web service for retrieving branches by id? This will be the third option if branch information is not often required.

Answer 4

Shortened and processed:

 public string BranchName(string branchId) { var bs = branchList.FirstOrDefault(b => b.Id == branchId); return bs == null ? null : bs.Name; }