LINQ uses something called deferred execution. This means that the LINQ query in Figure 1.4(from the previous post "Introduction to LINQ - Part1 (2 of many)" will not return anything until you choose to enumerate through the results using something like a foreach loop. Because of this, you can build your LINQ query little by little depending on the business logic. You can limit the amount of rows returned from the datasource as well as the strain on the datasource by narrowing down your selection criteria way before you ever open a connection to the data store. This is working in a disconnected environment at its best.
Not only is execution deferred but the entire query is being built into an expression tree in the background. This allows LINQ to be able to choose, at the endpoint once the expression tree is fully built and the query is complete, the appropriate and most efficient SQL query to execute. This eliminates the need for client side JOINS or any manual optimization we would need to use if concatenating a large SQL query using a StringBuilder, for instance.
Syntactic Sugar
It is very familiar to be able to write LINQ queries using the syntax in Figure 1.4 because most of us have written some kind of SQL query. The ability to write code in such a way that is easier to understand and more familiar, such as in the case with this LINQ query is called Syntactic Sugar.
So you’re on a diet, you say? Maybe you’ve got programmatic diabetes and don’t want any sugar? That is fine too, because there is another way we can write LINQ queries without it. We can also write the same LINQ query from Figure 1.4 using the syntax below.
Figure 1.5
people.Where(p => p.Age > 30);
The result of this query, when enumerated, will yield the same results as the query in Figure 1.4, but without the syntactic sugar. You may find, as I have, in some cases it is easier and more convenient to get results using the method in Figure 1.5, and sometimes the method in 1.4. The choice is completely a matter of preference and up for you to decide. The method in Figure 1.5, however, does need a little explaining if you have never seen the => operator before.
Lambda Functions
The argument for the “Where” method in Figure 1.5 is known as a Lambda function. Lambda functions have been around a lot longer than their use in .NET in the world of mathematics such as calculus, but the use of the technology behind a Lambda function in .NET has been around for quite some time.
A Lambda function is really nothing more than a way to write an inline delegate. A delegate, for those of you that don’t know, is basically a type safe function pointer.
Figure 1.6
public delegate void DoSomethingDelegate();
DoSomethingDelegate doSomething = new DoSomethingDelegate(MyCustomDoSomethingMethod);
In Figure 1.6 above, the “DoSomethingDelegate” type could then be the type set to a property of a class that would accept as a value any method (such as MyCustomDoSomethingMethod) that matched the signature of the DoSomethingDelegate set during declaration.
A Lambda function works the same way in that the argument of the “Where” method is a type of Func
To illustrate this, we can write the predicate (Where method) filtering in another way using a filter condition we previously created and then passed to the “Where” method of the List
Figure 1.7
Func
var r = people.Where(ageFilter);
Again, you can choose any of the methods in Figure 1.4, 1.5, or 1.7 to perform the operations you need.
Introduction to LINQ - Part1 Continued...
Final Sample Version of the Project can be download from the final post in this series - "Introduction to LINQ - Part1 (final of many)"
To see all posts on "Introduction to LINQ - Part1" Click on link to your right that says it.
Please do comment the post after you read, Thank you and have a good LINQ.
No comments:
Post a Comment