My Tuesday morning session was with Luca Bolognese, lead program manager on LINQ, covering a slightly different flavor than what Pablo Castro was demonstrating with ADO.NET vNext on Monday morning. Luca’s Italian accent was charming, but it was even more exciting to see what LINQ does on a deeper level.
He started by showing a classical problem that LINQ solves. Imagine a collection of integers which you need to filter out based on a certain criteria, something like:
int[] nums = {2,3,5,7,11};
It’s usually done with some kind of iteration in the form of:
int[] nums = { 2,3,5,7,11};
List<int> selected = new List<int>();
for (int i = 0; i <>
if (nums[i] > 4) {
selected.Add(nums[i]);
}
}
// selected represents my values
int[] nums = {2,3,5,7,11};
var selected = from i in nums
where i > 4
select i;
From the perspective of someone who writes the iteration + selection stuff every day, I think that LINQ is going to have a big impact on my code. But this is just the beginning. Luca then showed how LINQ is split out to target several different forms of data structures:
- LINQ to Objects (Anything implementing IEnumerable, collections etc… )
- LINQ enabled ADO.NET (mapping database structures to objects and then querying off of them)
- LINQ to XML
In a LINQ enabled ADO.NET scenario, you can take an object that is mapped to some entity in your database and query off of it. I don’t recall the exact demonstration, but an example would be querying a collection of “customer” objects based on some filter:
var topcustomers = from customer in customers
where customer.orderCount > 10
select {customer.id, customer.fullName};
I’ve heard a lot about ORM ever since my friend Aaron started talking about Hibernate (some time ago) but what catapults this over the typical ORM scenario is that the functionality is built into language and not abstracted through method calls. I’ve been a bit lukewarm to the notion since it seemed like a lot of work up front and because this type of abstraction where objects can represent data and provide some manipulative capacity is already built in the DataSet/DataTable model. However two things make LINQ enabled ADO.NET a little different: first, the IDE facilitates the mappings that are made through an “EDM” diagram and mapping providers that give a lot of flexibility in connecting to the datastore, secondly the developer wields a lot of control over how the mapping works and how things are updated – the queries, the stored procedures, all data access still belongs to you and not to some “tool.”
Finally the LINQ enabled XML is powerful – it exposes XML data to yet another format of “query” besides XQuery and XPath. There is also the ability to work with the hierarchical structure that XML documents sometimes expose as collections within collections. The LINQ processing, with a bit of instruction, can also be instructed how to retrieve content (depth first traversal, and so on).
Luca’s blog seems to have died, but for some interesting tidbits, it’s here. Maybe with a few hits it can start up again?
Posts
