ARB Security Solutions » Best Practice: Don’t Iterate SPListItems for IQueryable Support

Latest Free SharePoint Software

ARB Security Solutions regularly releases free SharePoint software, including WebParts, Client Applications, Framework Extensions, and other Miscellaneous Components.
The most recent freeware is:

Title: Simple SharePoint Rollup WebPart
Date Published: 10/22/2009

Previous Two Free WebPart Releases:

SharePoint Security Assurance Program™

For externally facing SharePoint deployments, security is an acutely important deployment concern. Learn how through daily security scanning, you can ensure external business users and partners that they can collaborate in confidence!

Security Assurance WebPart:

Start Audit Process With The SharePoint Security Assurance Program™

Best Practice: Don’t Iterate SPListItems for IQueryable Support

I saw this during a code review today. Essentially, to support a LINQ query into a SPListItemCollection, there was an iteration that converted the SPListItemCollection to a typed List collection, the secondary collection subsequently being queried through LINQ. While SPListItemCollection implements IEnumerable it is challenging to use when converting the instance to IQueryable because it will fall back on IEnumerable specification since it simplements IEnumerable, not IQueryable.

The method in question looked like this:

PLAIN TEXT

C#:

public static List<SPListItem> ConvertToTypedList(SPListItemCollection collection)
{
List<SPListItem> items = new List<SPListItem>();
foreach (SPListItem item in collection)
{
items.Add(item);
}
return items;
}

That iteration IMHO is entirely too expensive for performance reasons because of dual collection builds, and it’s just plain ugly. For each query run, execute collection generation of an already existing collection? No thanks!

Instead, just use Cast(), it's much cleaner and this is the exact situation it is used for. Replicating the intent of the above iteration, I can simply express in the domain terms (via method chaining) the LINQ query (which you can obviously modify with whatever query you like).

PLAIN TEXT

C#:

var results = SPContext.Current.Web.Lists["Some List"].Items.Cast<SPListItem>().Select(item => item);

For example, to using a where clause for a specific title:

PLAIN TEXT

C#:

var results = SPContext.Current.Web.Lists["Some List"].Items.Cast<SPListItem>().Where(item => item[SPBuiltInFieldId.Title].ToString() == "Title To Search");

Article Or Research Filed Under SharePoint| SharePoint Development.

4 Comments »

[...] Best Practice: Don’t Iterate SPListItems for IQueryable Support [...]

Pingback by Links (12/4/2008) « Steve Pietrek - Everything SharePoint — December 4, 2008 @ 8:03 pm
As a side question, do you think it’s better to use a LINQ query into an SPListItemCollection rather than using a CAML query (as in an SPQuery object)?

Comment by Oz Ortiz — December 5, 2008 @ 8:50 am
Hmmm, I prefer the LINQ query simply because everything is strongly typed, as opposed to relying on a string literal which is easier to mess up. I am not sure of the performance differences though.

Comment by Adam Buenz — December 5, 2008 @ 8:51 am
[...] Speaking of LINQ and SharePoint, check out Adam Buenz’s post on using LINQ’s IEnumerable.Cast<T> with SharePoint collections to get IQueryable support. And while using LINQ for filtering and such may be prettier, resist the urge to skip CAML altogether: there is definitely a performance advantage in filtering your SPListItemCollection with an SPQuery, especially for large lists. I can’t seem to find any hard data on this, so I nominate Waldek Mastykarz to investigate – his analyses of other performance topics were great. Posted in Object Model, SharePoint. Tags: anonymous type, dispose, extension method, SPSite.AllWebs, SPWebCollection. [...]

Pingback by Safely Process SPSite.AllWebs « Solutionizing .NET — December 7, 2008 @ 1:14 am