|
As I was writing code for a chapter last night, I thought to myself: "Self, it would be really cool if you could use LINQ to manipulate the SharePoint object model instead of all these klunky old loops." Well, thats exactly right. Since LINQ queries work on any in-memory object that implements IEnumerable, robust (but often difficult to use) object models are already exposed to LINQ and ready to be improved.
First, let's take a look at some sample code that builds a List of SPList instances where the list is hidden on a given site:
SPSite site = new SPSite("http://server/site");
SPWeb web = site.AllWebs[0];
List<SPList> hiddenLists = new List<SPlist>(); // Do not use an SPListCollection here
foreach (SPList list in web.Lists)
{
if (list.Hidden)
hiddenLists.Add(list);
}This doesn't look that bad... But if you have been using LINQ at all, you know you can do this in one very easy to read line of code:
var hiddenLists = from list in web.Lists where list.Hidden select list;
Doesn't that look and feel much better? I think so. You could even make your own generic, flexible lambda function that can be used as a filter mechanism for lists. If you want more information on lambda expressions, check out my blog entry, Lambda Lambda Lambda.
What if you wanted to sort the lists in descending order by title? Usually, on in-memory structures this is either a pain in the butt, or just never looks good. With LINQ, its ridiculously easy:
var hiddenLists = from list in web.Lists orderby list.Title descending where list.Hidden select list;
Let's say you plan on accessing the hidden list collection a lot. What if you then also plan on performing queries on the hidden list. In this case, it doesn't really make sense to generate the hidden list collection using a standard query, since you're going to run a query off that and nested queries can get difficult to use. What if you decided to make a language extension to the SPListCollection class that simply returned the hidden items? Now we're talkin:
static class SPListCollectionExtender
{
public static List<SPList> AllHidden(this SPListCollection input)
{
return
(from list in input where list.Hidden select list).ToList();
}
}
With that in place, you can then display the titles of all hidden lists in a given SPListCollection class like this:
foreach (SPList hiddenList in web.Lists.AllHidden)
{
Console.WriteLine("{0}", hiddenList.Title);
}
Programming with LINQ in mind often requires a whole new way of thinking. However, I strongly recommend that everyone start trying to think the "LINQ" way now.. As you can see, with just a few simple tweaks here and there, the cleanliness and efficiency of your code can be drastically improved - without even touching on any of the additional functionality coming up like the ADO.NET Entity Framework.
You are now part of the BUZZ, Sharepoint BUZZ
you know just had a nasty thought about the entity framework ... like
almost all MS prebuilt technologies will this only work with static
connection strings? my connection strings are not in my web.config, they
are dynamic and loaded based on the site being requested .... I hope this
is supported :) it will suck if you can't work like this ... membership is
another area where you can't overload the connection string objects.
Kevin, I don't know a lot about Sharepoint, but I assume that those lists
can have a lot of data in them, so I highly recommend that you don't use
LINQ like you are suggesting.
You might be interested in the LINQ to SharePoint project on CodePlex too.
The goal of the project is to create a custom LINQ provider that supports
translation of LINQ queries into CAML queries for SharePoint lists,
together with an entity model.
check out my Linq to Google on codeplex
http://www.codeplex.com/glinq
Hi Kevin,