Using Lamba expression to process SharePoint objects (or any data you need to process)

This is just a trick to make your life easier. You can use this against any data in SharePoint as long as you do not need performance critical functionality. Remember that doing lambda expressions against big objects such as get an SPWeb or going through a list of SPWeb is still going to cost you the memory allocation and CPU utilization.

Sample how to remove an event receiver from a list:

using System.Linq;

var eventReceiver = list.EventReceivers.Cast<SPEventReceiverDefinition>().SingleOrDefault(o => o.Class.ToLower().Contains(receiverClass.ToLower()));
if (eventReceiver != null)
{
var allowUnsafeUpdates = web.AllowUnsafeUpdates;
web.AllowUnsafeUpdates = true;
eventReceiver.Delete();
list.Update();
web.Update();

web.AllowUnsafeUpdates = allowUnsafeUpdates;
}

Remember the concepts Late binding, Delayed Execution and Captured Variables.

Check you this Explanation from StackOverflow http://stackoverflow.com/questions/8930024/linq-late-binding-confusion =>

Late-binding: This is where the meaning of code is determined after it was compiled. For example, x.DoStuff() is early-bound if the compiler checks that objects of x‘s type have a DoStuff() method (considering extension methods and default arguments too) and then produces the call to it in the code it outputs, or fails with a compiler error otherwise. It is late-bound if the search for the DoStuff() method is done at run-time and throws a run-time exception if there was no DoStuff() method. There are pros and cons to each, and C# is normally early-bound but has support for late-binding (most simply through dynamic but the more convoluted approaches involving reflection also count).

Delayed execution: Strictly speaking, all Linq methods immediately produce a result. However, that result is an object which stores a reference to an enumerable object (often the result of the previous Linq method) which it will process in an appropriate manner when it is itself enumerated. For example, we can write our own Take method as:

private static IEnumerable<T> TakeHelper<T>(IEnumerable<T> source, int number)
{
  foreach(T item in source)
  {
    yield return item;
    if(--number == 0)
      yield break;
  }
}
public static IEnumerable<T> Take<T>(this IEnumerable<T> source, int number)
{
  if(source == null)
    throw new ArgumentNullException();
  if(number < 0)
    throw new ArgumentOutOfRangeException();
  if(number == 0)
    return Enumerable.Empty<T>();
  return TakeHelper(source, number);
}

Now, when we use it:

var taken4 = someEnumerable.Take(4);//taken4 has a value, so we've already done
                                    //something. If it was going to throw
                                    //an argument exception it would have done so
                                    //by now.

var firstTaken = taken4.First();//only now does the object in taken4
                                        //do the further processing that iterates
                                        //through someEnumerable.

Captured variables: Normally when we make use of a variable, we make use of how its current state:

int i = 2;
string s = "abc";
Console.WriteLine(i);
Console.WriteLine(s);
i = 3;
s = "xyz";

It’s pretty intuitive that this prints 2 and abc and not 3 and xyz. In anonymous functions and lambda expressions though, when we make use of a variable we are “capturing” it as a variable, and so we will end up using the value it has when the delegate is invoked:

int i = 2;
string s = "abc";
Action λ = () =>
{
  Console.WriteLine(i);
  Console.WriteLine(s);
};
i = 3;
s = "xyz";
λ();

Creating the λ doesn’t use the values of i and s, but creates a set of instructions as to what to do with i and s when λ is invoked. Only when that happens are the values of i and s used.

Putting it all together: In none of your cases do you have any late-binding. That is irrelevant to your question.

In both you have delayed execution. Both the call to Take and the call to Where return enumerable objects which will act upon arr when they are enumerated.

In only one do you have a captured variable. The call to Take passes an integer directly to Take and Take makes use of that value. The call to Where passes a Func<int, bool> created from a lambda expression, and that lambda expression captures an int variable. Where knows nothing of this capture, but the Func does.

That’s the reason the two behave so differently in how they treat cutoff. ” http://stackoverflow.com/questions/8930024/linq-late-binding-confusion

 

Microsoft sources of info:

Lambda Expressions (C# Programming Guide)

Getting Started with LINQ in C#

101 LINQ Samples

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s